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EXECUTIVE  SUMMARY 


--This  Validation  Summary  Report  (VSR)  summarizes  the  results  and  conclusions 
of  validation  testing  performed  on  the  Tandem  Ada®  Compiler,  Release 
T9270C00,  using  Version  1.8  of  the  Ada  Compiler  Validation  Capability 
(ACVC).  The  Tandem  Ada  Compiler  is  hosted  on  a  Tandem  NonStop©  VLX 
operating  under  GUARDIAN  90,  Version  COO.  Programs  processed  by  this 

compiler  may  be  executed  on  a  Tandem  NonStop  VLX  operating  under  GUARDIAN 
90,  Version  COO.' 

On-site  testing  was  performed  15  May  1987  through  20  May  1987  at  Tandem 
Computers,  Cupertino  CA,  under  the  direction  of  the  Ada.  Validation  Facility^ 
according  to  Ada  Validation  Organization  >(AVO)  policies  and 
procedures.  The  AVF  identified  2222  of  the  2399  tests  in  ACVC  Ve-sion  1.8 
to  be  processed  during  on-site  testing  of  the  compiler.  The  19  tests 
withdrawn  at  the  time  of  validation  testing,  as  well  as  the  158  executable 
tests  that  make  use  of  floating-point  precision  exceeding  that  supported  by 
the  implementation,  were  not  processed.  After  the  2222  tests  were 

processed,  results  for  Class  A,  C,  D,  and  E  tests  were  examined  for  correct 
execution.  Compilation  listings  for  Class  B  tests  were  analyzed  for 
correct  diagnosis  of  syntax  and  semantic  errors.  Compilation  and  link 
results  of  Class  L  tests  were  analyzed  for  correct  detection  of  errors. 
There  were  38  of  the  processed  tests  determined  to  be  inapplicable.  The 
remaining  2184  tests  were  passed.  . 

The  results  of  validation  are  summarized  in  the  following  table: 


RESULT 
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CHAPTER 
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TOTAL 

116 

330 
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247 
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98 
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32 
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2399 

The  AVF  concludes  that  these  results  demonstrate  acceptable  conformity  to 
ANSI/MIL- STD- 18 15A  Ada. 


®Ada  is  a  registered  trademark  of  the  United  States  Government 
(Ada  Joint  Program  Office). 

©NonStop  is  a  trademark  of  Tandem  Computers 


i 


Ada®  COMPILER 

VALIDATION  SUMMARY  REPORT: 

Tandem  Computers 

Tandem  Ada  Compiler,  Release  T9270C00 
Tandem  NonStop  ©VLX  host  and  target 


j 


> 


Completion  of  On-Site  Testing: 
20  May  1987 


Prepared  By: 

Ada  Validation  Facility 
ASD/SCOL 

Wright-Patterson  AFB  OH  45433-6503 


Prepared  For: 

Ada  Joint  Program  Office 
United  States  Department  of  Defense 
Washington,  D.C. 


(- 

\ 

# 

i 


®Ada  is  a  registered  trademark  of  the  United  States  Government 
(Ada  Joint  Program  Office). 

^NonStop  is  a  trademark  of  Tandem  Computers 


Ada  Compiler  Validation  Summary  Report: 


Compiler  Name:  Tandem  Ada  Compiler,  Release  T9270C00 

Host:  Target: 

Tandem  NonStop®  VLX  under  Tandem  NonStop  VLX  under 

GUARDIAN  90,  Version  COO  GUARDIAN  90,  Version  COO 

Testing  Completed  20  May  1987  Using  ACVC  1.8 


This  report  has  been  reviewed  and  is  approved. 


Ada  Validation  Facility 
Georgeanne  Chitwood 
ASD/SCOL 

Wright-Patterson  AFB  OH  45433-6503 


Ada  Validation  Organization 
Dr.  John  F.  Kramer 
Institute  for  Defense  Analyses 
Alexandria  VA 


Ada  Jdlnt  Program  Office 
Virginia  L.  Caster 
Director 

Department  of  Defense 
Washington  DC 


®Ada  is  a  registered  trademark  of  the  United  States  Government 
(Ada  Joint  Program  Office). 

©NonStop  is  a  trademark  of  Tandem  Computers 


EXECUTIVE  SUMMARY 


This  Validation  Summary  Report  (VSR)  summarizes  the  results  and  conclusions 
of  validation  testing  performed  on  the  Tandem  Ada ?  Compiler,  Release 
T9270C00,  using  Version  1.8  of  the  Ada  Compiler  Validation  Capability 
( ACVC ) .  The  Tandem  Ada  Compiler  is  hosted  on  a  Tandem  MonStopGvLX 

operating  under  GUARDIAN  90,  Version  COO.  Programs  processed  by  this 
compile.-  may  be  executed  on  a  Tandem  NonSiop  VLX  operating  under  GUARDIAN 
90,  Version  COO. 

On-site  testing  was  performed  15  May  1987  through  20  May  1987  at  Tandem 
Computers,  Cupertino  CA,  under  the  direction  of  the  Ada  Validation  Facility 
(AVF),  according  to  Ada  Validation  Organization  (AVO)  policies  and 

procedures.  The  AVF  identified  2222  of  the  2399  tests  in  ACVC  Version  1.8 
to  be  processed  during  on-site  testing  of  the  compiler.  The  19  tests 

withdrawn  at  the  time  of  validation  testing,  as  well  as  the  158  executable 

tests  that  make  use  of  floating-point  precision  exceeding  that  supported  by 
the  implementation,  were  not  processed.  After  the  2222  tests  were 
processed,  results  for  Class  A,  C,  D,  and  E  tests  were  examined  for  correct 
execution.  Compilation  listings  for  Class  B  tests  were  analyzed  for 
correct  diagnosis  of  syntax  and  semantic  errors.  Compilation  and  link 
results  of  Class  L  tests  were  analysed  for  correct  detection  of  errors. 
There  were  38  of  the  processed  tests  determined  to  be  inapplicable.  The 
remaining  2184  tests  were  passed. 

The  results  of  validation  are  summarized  in  the  following  table: 
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The  AVF  concludes  that  these  results  demonstrate  acceptable  conformity  to 
ANSI/MIL-STD- 18 1 5 A  Ada. 
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CHAPTER  1 


INTRODUCTION 


This  Validation  Summary  Report  (VSR)  describes  the  extent  to  which  a 
specific  Ada  compiler  conforms  to  the  Ada  Standard,  ANSI/MIL-STD-1815A. 
This  report  explains  all  technical  terms  used  within  it  and  thoroughly 
reports  the  results  of  testing  this  compiler  using  the  Ada  Compiler 
Validation  Capability  (ACVC).  An  Ada  compiler  must  be  implemented 
according  to  the  Ada  Standard,  and  any  implementation-dependent  features 
must  conform  to  the  requirements  of  the  Ada  Standard.  The  Ada  Standard 
must  be  implemented  in  its  entirety,  and  nothing  can  be  implemented  that  is 
not  in  the  Standard. 

Even  though  all  validated  Ada  compilers  conform  to  the  Ada  Standard,  it 
must  be  understood  that  some  differences  do  exist  between  implementations. 
The  Ada  Standard  permits  some  implementation  dependencies--for  example,  the 
maximum  length  of  identifiers  or  the  maximum  values  of  integer  types. 
Other  differences  between  compilers  result  from  characteristics  of 
particular  operating  systems,  hardware,  or  implementation  strategies.  All 
of  the  dependencies  observed  during  the  process  of  testing  this  compiler 
are  given  in  this  report. 

The  information  in  this  report  is  derived  from  the  test  results  produced 
during  validation  testing.  The  validation  process  includes  submitting  a 
suite  of  standardized  tests,  the  ACVC,  as  inputs  to  an  Ada  compiler  and 
evaluating  the  results.  The  purpose  of  validating  is  to  ensure  conformity 
of  the  compiler  to  the  Ada  Standard  by  testing  that  the  compiler  properly 
implements  legal  language  constructs  and  that  it  identifies  and  rejects 
illegal  language  constructs.  The  testing  also  identifies  behavior  that  is 
implementation  dependent  but  permitted  by  the  Ada  Standard.  Six  classes  of 
tests  are  used.  These  tests  are  designed  to  perform  checks  at  compile 
time,  at  link  time,  and  during  execution. 
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1.1  PURPOSE  OF  THIS  VALIDATION  SUMMARY  REPORT 

This  VSR  documents  tne  results  of  the  validation  testing  performed  on  an 
Ada  compiler.  Testing  was  carried  out  for  the  following  purposes: 

.  To  attempt  to  identify  any  language  constructs  supported  by  the 
compiler  that  do  not  conform  to  the  Ada  Standard 

.  To  attempt  to  identify  any  unsupported  language  constructs 
required  by  the  Ada  Standard 

.  To  determine  that  the  implementation-dependent  behavior  is  allowed 
by  the  Ada  Standard 


Testing  of  this  compiler  was  conducted  by  SofTech,  Inc.,  under  the 
direction  of  the  AVF  according  to  policies  and  procedures  established  by 
the  Ada  Validation  Organization  (AVO).  On-site  testing  was  conducted  from 
15  May  1987  through  20  May  1987  at  Tandem  Computers,  Cupertino  CA. 


1.2  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  AVO  may 
make  full  and  free  public  disclosure  of  this  report.  In  the  United  States, 
this  is  provided  in  accordance  with  the  "Freedom  of  Information  Act"  (5 
U.S.C.  #55 2).  The  results  of  this  validation  apply  only  to  the  computers, 
operating  systems,  and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  net 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  subject  compiler  has  no  nonconformities 
to  the  Ada  Standard  other  than  those  presented.  Copies  of  this  report  are 
available  to  the  public  from: 

Ada  Information  Clearinghouse 
Ada  Joint  Program  Office 
OUSDRE 

The  Pentagon,  Rm  3D— 1 39  (Fern  Street) 

Washington  DC  20301-3081 

or  from: 


Ada  Validation  Facility 
A3D/SC0L 

Wright-Patterson  AFB  OH  ^54 33—  6503 
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Questions  regarding  this  report  or  the  validation  test  results  should 
directed  to  the  AVF  listed  aoove  or  to: 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria  VA  2231 1 


1.3  REFERENCES 


1.  Reference  Manual  for  the  Ada  Programmi  ng  Language , 

ANSI/MIL-STD- 1 8 1 5 A ,  February  1983. 

2.  Ada  Validation  Organization :  Procedures  and  Guidelines ,  Ada  Joint 
Program  Office,  1  January  1 987 - 

3.  Ada  Compiler  Validation  Capability  Implementer3 '  Guide ,  SofTech, 
Inc.,  December  1984. 


1.4  DEFINITION  OF  TERMS 


AC  VC 


The  Ada  Compiler  Validation  Capability.  A  set  of  programs 
that  evaluates  the  conformity  of  a  compiler  to  the  Ada 
language  specification,  ANSI/MIL-STD- 1 8 1 5A . 


Ada  Standard  ANSI/MIL-STD- 1 8 15A,  February  1983- 


Applicant  The  agency  requesting  validation. 


AVF 


AVO 


Compiler 


The  Ada  Validation  Facility.  In  the  context  of  this  report, 
the  AVF  is  responsible  for  conducting  compiler  validations 
according  to  established  policies  and  procedures. 

The  Ada  Validation  Organization.  In  the  context  of  this 
report,  the  AVO  is  responsible  for  setting  procedures  for 
compiler  validations. 

A  processor  for  the  Ada  language.  In  the  context  of  this 
report,  a  compiler  is  any  language  processor,  including 
cross-compilers,  translators,  and  interpreters. 


Failed  test  A  test  for  which  the  compiler  generates  a  result  that 
demonstrates  nonconformity  to  the  Ada  Standard. 


Host 


The  computer  on  which  the  compiler  resides. 
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Inapplicable  A  test  that  uses  features  of  the  language  that  a  compiler  is 
test  not  required  to  support  or  say  legitimately  support  in  a  way 

utner  tr.an  the  one  expected  by  tne  test. 

Passed  test  A  test  for  which  a  compiler  generates  the  expected  result. 


Target 

Test 


Withdrawn 

test 


The  computer  for  which  a  compiler  generates  code. 

A  program  that  checks  a  compiler's  conformity  regarding  a 
particular  feature  or  features  to  the  Ada  Standard.  In  the 
context  of  this  report,  the  term  is  used  to  designate  a 
single  test,  which  may  comprise  one  or  more  files. 

A  test  found  to  be  incorrect  and  not  used  to  check  conformity 
to  the  Ada  language  specification.  A  test  may  be  incorrect 
because  it  has  an  invalid  test  objective,  fails  to  meet  its 
test  objective,  or  contains  illegal  or  erroneous  use  of  the 
language . 


1.5  ACVC  TEST  CLASSES 

Conformity  to  the  Ada  Standard  is  measured  using  the  ACVC.  The  ACVC 
contains  both  legal  and  illegal  Ada  programs  structured  into  six  test 
classes:  A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies 
the  class  to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable, 
and  special  program  units  are  used  to  report  their  results  during 
execution.  Class  B  tests  are  expected  to  produce  compilation  errors. 
Class  L  tests  are  expected  to  produce  link  errors. 

Class  A  tests  check  that  legal  Ada  programs  can  be  successfully  compiled 
and  executed.  However,  no  checks  are  performed  during  execution  to  see  if 
the  test  objective  has  been  met.  For  example,  a  Class  A  test  checks  that 
reserved  words  of  another  language  (other  than  those  already  reserved  in 
the  Ada  language)  are  not  treated  as  reserved  words  by  an  Ada  compiler.  A 
Class  A  test  is  passed  if  r.o  errors  are  detected  at  compile  time  ana  the 
program  executes  to  produce  a  PASSED  message. 

Class  3  tests  cneck  that  a  compiler  detects  illegal  language  usage.  Class 
3  tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  compilation  listing  is  examined  to  verify  that  every  syntax  or 
semantic  error  in  the  test  is  detected.  A  Class  3  test  is  passed  if  every 
illegal  construct  that  it  contains  is  detected  by  the  compiler. 

Class  C  tests  check  that  legal  Ada  programs  can  be  correctly  compiled  and 
executed.  Each  Class  C  test  is  self-checking  and  produces  a  PASS 30, 
FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  wnen  it  is 
executed . 

Class  D  tests  check  the  compilation  and  execution  capacities  of  a  compiler. 
Since  there  are  no  capacity  requirements  placed  on  a  compiler  by  the  Ada 
Standard  for  some  parameters — f or  example,  the  number  of  identifiers 
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permitted  in  a  compilation  or  the  number  of  units  in  a  library — a  compiler 
may  refuse  to  compile  a  Class  D  test  and  still  be  a  conforming  compiler. 
Therefore,  if  a  Class  D  test  fails  to  compile  oecause  tne  capacity  of  the 

compiler  is  exceeded,  the  test  is  classified  as  inapplicable.  If  a  Class  D 

test  compiles  successfully,  it  is  self-checking  and  produces  a  PASSED  or 
FAILED  message  during  execution. 

Each  Class  E  test  is  self-checking  and  produces  a  NOT  APPLICABLE,  PASSED, 
or  FAILED  message  wnen  it  is  compiled  and  executed.  However,  the  Ada 

Standard  permits  an  implementation  to  reject  programs  containing  some 

features  addressed  by  Class  E  tests  during  compilation.  Therefore,  a  Class 
S  test  is  passed  by  a  compiler  if  it  is  compiled  successfully  and  executes 
to  produce  a  PASSED  message,  or  if  it  is  rejected  by  the  compiler  for  an 
allowable  reason. 

Class  L  tests  check  that  incomplete  or  illegal  Ada  programs  involving 
multiple,  separately  compiled  units  are  detected  and  not  allowed  to 
execute.  Class  L  tests  are  compiled  separately  and  execution  is  attempted. 
A  Class  L  test  passes  if  it  is  rejected  at  link  time — that  is,  an  attempt 
to  execute  the  main  program  must  generate  an  error  message  before  any 
declarations  in  the  main  program  or  any  units  referenced  by  the  main 
program  are  elaborated. 

Two  library  units,  the  package  REPORT  and  the  procedure  CHECK_FILE,  support 
the  self-checking  features  of  the  executable  tests.  The  package  REPORT 
provides  the  mechanism  by  which  executable  tests  report  PASSED,  FAILED,  or 
NOT  APPLICABLE  results.  It  also  provides  a  set  of  identity  functions  used 
to  defeat  some  compiler  optimizations  allowed  by  the  Ada  Standard  that 
would  circumvent  a  test  objective.  Tne  procedure  CHECK_FILE  is  used  to 
check  the  contents  of  text  files  written  by  some  of  the  Class  C  tests  for 
chapter  14  of  the  Ada  Standard.  Tne  operation  of  these  units  is  checked  by 
a  set  of  executable  tests.  These  tests  produce  messages  that  are  examined 
to  verify  that  the  units  are  operating  correctly.  If  these  units  are  not 
operating  correctly,  then  the  validation  is  not  attempted. 

The  text  of  the  tests  in  the  ACVC  follow  conventions  that  are  intended  to 
ensure  that  the  tests  are  reasonably  portable  without  modification.  For 
example,  the  tests  make  use  of  only  the  basic  set  of  55  characters,  contain 
lines  witn  a  maximum  length  of  72  characters,  use  small  numeric  values,  and 
place  features  that  may  not  be  supported  by  ail  implementations  in  separate 
tests.  However,  some  tests  contain  values  that  require  the  test  to  be 
customized  according  to  implementation-specific  values--for  example,  an 
illegal  file  name.  A  list  of  the  values  used  for  this  validation  is 
provided  in  Appendix  C. 

A  compiler  must  correctly  process  each  of  the  tests  in  the  suite  and 
demonstrate  conformity  to  the  Ada  Standard  by  either  meeting  the  pass 
criteria  given  for  the  test  or  by  showing  that  the  test  is  inapplicable  to 
the  implementation.  The  applicability  of  a  test  to  an  implementation  is 
considered  each  time  the  implementation  is  validated.  A  test  that  is 
inapplicable  for  one  validation  is  not  necessarily  inapplicable  for  a 
subsequent  validation. 


1-5 


INTRODUCTION 


Any  test  that  was  determined  to  contain  an  illegal  language  construct  or  an 
erroneous  language  construct  is  withdrawn  from  the  ACVC  and,  therefore,  is 
not  used  in  testing  a  compiler.  The  tests  withdrawn  at  tne  time  of 
validation  are  given  in  Appendix  D. 
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CONFIGURATION  INFORMATION 


2.1  CONFIGURATION  TESTED 

The  candidate  compilation  system  for  this  validation  was  tested  under  the 
following  configuration: 


Compiler:  Tandem  Ada  Compiler,  Release  T9270C00 
ACVC  Version:  1.8 
Certificate  Number:  870515W1 .08089 
Host  Computer: 

Machine : 

Operating  System: 

Memory  Size: 


Tandem  NonStop  VLX 

GUARDIAN  90 
Version  COO 

8  megabytes 


Target  Computer: 

Machine : 

Operating  System: 

Memory  Size: 


Tandem  NonStop  VLX 

GUARDIAN  90 
Version  COO 

8  megabytes 
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2.2  IMPLEMENTATION  CHARACTERISTICS 

One  of  ;ne  purposes  of  validating  compilers  is  to  determine  the  behavior  of 
a  compiler  in  those  areas  of  the  Ada  Standard  that  permit  implementations 
to  differ.  Class  D  and  E  tests  specifically  check  for  such  implementation 
differences.  However,  tests  in  other  classes  also  characterize  an 

implementation.  This  compiler  is  characterized  by  the  following 
interpretations  of  the  Ada  Standard: 


.  Capacities. 

The  compiler  correctly  processes  tests  containing  loop  statements 
nested  to  65  levels,  block  statements  nested  to  65  levels,  and 
recursive  procedures  separately  compiled  as  subunits  nested  to  17 
levels.  It  correctly  processes  a  compilation  containing  723 
variables  in  the  same  declarative  part.  (See  tests  D55A03A..H  (8 

tests),  D56001B,  D64005E..G  (3  tests),  and  D29002K.) 


.  Universal  integer  calculations. 

An  implementation  is  allowed  to  reject  universal  integer 
calculations  having  values  that  exceed  SYSTEM.MAX_INT.  This 
implementation  does  not  reject  such  calculations  and  processes 
them  correctly.  (See  tests  D4A002A,  D4A002B,  D4A004A,  and 

D4A004B.) 


Predefined  types. 

This  implementation  supports  the  additional  predefined  types 
SHORT_INTEGER ,  LONG_INTEGER,  L0NG_FL0AT,  and  LONG_LONG__INTEGER  in 
the  package  STANDARD.  (See  tests  B86001C  and  B86001D.) 


.  Based  literals. 

An  implementation  is  allowed  to  reject  a  based  literal  with  a 
value  exceeding  SYSTEM. MAX_INT  during  compilation,  or  it  may  raise 
NUMER IC_ER R  0  R  or  CONSTRAINT_ERROR  during  execution.  This 
implementation  raises  NUMERIC_ERROR  during  execution.  (See  test 
E24101A.) 


.  Array  types. 

An  implementation  is  allowed  to  raise  NUMERIC_ERROR  or 
CONSTRAINT_ERROR  for  an  array  having  a  'LENGTH  that  exceeds 
STANDARD. INTEGER 'LAST  and/or  SYSTEM. MAX  INT. 
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A  packed  BOOLEAN  array  having  a  'LENGTH  exceeding  INTEGER 'LAST 
raises  STORAGE_ERROR  when  the  array  objects  are  declared.  (See 
test  C52103X.) 

A  packed  two-dimensional  BOOLEAN  array  with  more  than  INTEGER' LAST 
components  raises  STORAGE_ERROR  when  the  array  object  is  declared. 
(See  test  C52104Y.) 

A  null  array  with  one  dimension  of  length  greater  than 
INTEGER' LAST  may  raise  NUMERIC_ERROR  or  CONSTRAINT_ERROR  either 
when  declared  or  assigned.  Alternatively,  an  implementation  may 
accept  the  declaration.  However,  lengths  must  match  in  array 
slice  assignments.  This  implementation  raises  no  exceptions. 
(See  test  E52103Y.) 

In  assigning  one-dimensional  array  types,  the  expression  appears 
to  be  evaluated  in  its  entirety  before  CONSTRAINT_ERROR  is  raised 
when  checking  whether  the  expression's  subtype  is  compatible  with 
the  target's  subtype.  In  assigning  two-dimensional  array  types, 
the  expression  does  not  appear  to  be  evaluated  in  its  entirety 
before  CONSTRAINT_ERROR  is  raised  when  checking  whether  the 
expression's  subtype  is  compatible  with  the  target's  subtype. 
(See  test  C52013A.) 


Discriminated  types. 

During  compilation,  an  implementation  is  allowed  to  either  accept 
or  reject  an  incomplete  type  with  discriminants  that  is  used  in  an 
access  type  definition  with  a  compatible  discriminant  constraint. 
This  implementation  accepts  such  subtype  indications.  (See  test 
E3S104A.) 

In  assigning  record  types  with  discriminants,  the  expression 
appears  to  be  evaluated  in  its  entirety  Defore  CONSTRAINT_ERROR  is 
raised  when  checking  whether  the  expression's  subtype  is 
compatible  with  the  target's  subtype.  (See  test  C52013A.) 


Aggregates . 

In  the  evaluation  of  a  multi-dimensional  aggregate,  all  choices 
appear  to  be  evaluated  before  checking  against  the  index  type. 
(See  tests  C43207A  and  C43207B.) 

In  the  evaluation  of  an  aggregate  containing  subaggregates,  all 
choices  are  not  evaluated  before  bei.^g  checked  for  identical 
bounds.  (See  test  E43212B.) 

All  choices  are  not  evaluated  before  CONSTRAINT_ERROR  is  raised  if 
a  bound  in  a  nonnull  range  of  a  nonnull  aggregate  does  not  belong 
to  an  index  subtype.  (See  test  E43211B.) 
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.  Functions, 

An  implementation  may  allow  the  declaration  of  a  parameteriess 
function  and  an  enumeration  literal  having  the  same  profile  in  the 
same  immediate  scope,  or  it  may  reject  the  function  declaration. 
If  it  accepts  the  function  declaration,  the  use  of  the  enumeration 
literal's  identifier  denotes  the  function.  This  implementation 
rejects  the  declaration.  (See  test  E66001D.) 


.  Representation  clauses. 

The  Ada  Standard  does  not  require  an  implementation  to  support 
representation  clauses.  If  a  representation  clause  is  not 
supported,  then  the  implementation  must  reject  it.  While  the 
operation  of  representation  clauses  is  not  checked  by  Version  1.8 
of  the  ACVC,  they  are  used  in  testing  other  language  features. 
This  implementation  accepts  'SIZE  and  'STORAGE_SIZE  for  tasks,  and 
'SMALL  clauses;  it  rejects  'STORAGE_SIZE  for  collections. 
Enumeration  representation  clauses  appear  not  to  be  supported. 
(See  tests  C55B16A,  C87B62A,  C87B62B,  C87B62C,  and  BC1002A.) 


.  Pragmas . 

The  pragma  INLINE  is  supported  for  procedures  and  functions.  (See 
tests  CA3004E  and  CA3004F.) 


.  Input /output . 

The  package  SEQUENTIAL_IO  cannot  be  instantiated  with 
unconstrained  array  types  and  record  types  with  discriminants 
without  defaults.  The  package  DIRECT_IO  cannot  be  instantiated 
with  unconstrained  array  types  and  record  types  w'.th  discriminants 
without  defaults.  (See  tests  AE2101C,  AE2101H,  CE2201D,  CE2201E, 

and  CE240 ID. ) 

An  existing  text  file  can  be  opened  in  OUT  FILE  mode,  but  cannot 
be  created  in  OUT_FILE  or  IN_FILE  mode.  (See  test  EE3102C.) 

More  than  one  internal  file  can  be  associated  with  each  external 
file  for  text  I/O  for  reading  only.  (See  tests  CE31HA..E  (5 
tests). ) 

More  than  one  Internal  file  can  be  associated  with  each  external 
file  for  sequential  I/O  for  reading  only.  (See  tests  CE2107A..F 
(6  tests).) 

More  than  one  internal  file  can  be  associated  with  each  external 
file  for  direct  I/O  for  reading  only.  (See  tests  CE2107A..F  (6 
tests) . ) 
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Temporary  sequential  files  are  given  a  name.  Temporary  direct 
files  are  given  a  name.  Temporary  files  given  names  are  deleted 
wren  they  are  closed.  .See  tests  CE210tA  ana  3E2133C.) 


3enerics . 

Separate  compilation  of  generic  bodies  with:  it  specifications  is 
not  supported  by  this  implementation.  iSee  tests  BA101 1C, 
CA1012A,  CA2009C,  CA2009F  and  BC3205D.) 
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3.1  TEST  RESULTS 

Version  1.8  of  the  ACVC  contains  2399  tests.  When  validation  testing  of 
Tandem  Ada  Compiler  was  performed,  19  tests  had  been  withdrawn.  The 
remaining  2380  tests  were  potentially  applicable  to  this  validation.  The 
AVF  determined  that  1 96  tests  were  inapplicable  to  this  implementation,  and 
that  the  2184  applicable  tests  were  passed  by  the  implementation. 

The  AVF  concludes  that  the  testing  results  demonstrate  acceptable 
conformity  to  the  Ada  Standard. 


3.2  SUMMARY  OF  TEST  RESULTS  EY  CLASS 


RESULT  TEST  CLASS  TOTAL 


A 

B 

C 

D 

E 

L 

Pas®d 

67 

865 

1 178 

17 

13 

44 

2184 

Failed 

0 

0 

0 

0 

0 

0 

0 

Inapplicable 

2 

2 

190 

0 

0 

2 

196 

Withdrawn 

0 

7 

12 

0 

0 

0 

19 

TOTAL 

69 

874 

1380 

17 

13 

46 

2399 
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3.3  SUMMARY  OF  TEST  RESULTS  BY  CHAPTEF 


RESULT 

2 

3 

4 

5 

6 

CHAPTER 

7  8  9 

10 

1  1 

12 

1  4 

TOTAL 

Passed 

103 

258 

339 

246 

161 

97 

137 

260 

1  24 

32 

2  17 

210 

2184 

Failed 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Inapplicaole 

13 

67 

31 

1 

0 

0 

2 

2 

6 

0 

1 

23 

196 

Withdrawn 

0 

5 

5 

0 

0 

1 

1 

2 

4 

0 

1 

0 

19 

TOTAL 

1  16 

330 

425 

247 

1 6 1 

93 

140 

264 

134 

32 

219 

233 

2399 

3.4  WITHDRAWN  TESTS 

The  following  19  tests  were  withdrawn  from  ACVC  Version  1.8  at  the  time  of 
this  validation: 


C 321 1 4A 
B33203C 
C34018A 
C35904A 
B37401A 


C41404A  B74101B 

S45116A  C87B50A 

C48008A  C92005A 

B49006A  CS40ACA 

34A010C  CA3005A..D  (4  tests) 

BC3204C 


See  Appendix  D  for  the  reason  that  each  of  these  tests  was  withdrawn. 


3.5  INAPPLICABLE  TESTS 

Some  tests  do  not  apply  to  all  compilers  because  they  make  use  of  features 
that  a  compiler  is  not  required  by  the  Ada  Standard  to  support.  Others  may 
depend  on  the  result  of  another  test  that  is  either  inapplicable  or 
withdrawn.  The  applicability  of  a  test  to  an  implementation  is  considered 
each  time  a  validation  is  attempted.  A  test  that  is  inapplicable  for  one 
validation  is  not  necessarily  inapplicable  for  a  subsequent  attempt.  For 
this  validation  attempt,  196  tests  were  inapplicable  for  the  reasons 
indicated: 

.  C34001F  and  C35702A  use  SH0RT_FL0 AT  which  is  not  supported  by  this 

compiler. 

.  C43212A  makes  assumptions  about  the  order  of  operations  during  the 

evaluation  of  an  array  aggregate.  This  implementation  raises 
CONSTRAINT_ERROR  after  evaluating  two  of  the  lower  bounds  and 
determining  that  they  don't  match,  while  the  test  considers  it  an 


3-2 


error  if  at  least  two  of  the  upper  bounds  aren't  also  evaluated. 
The  AVO  has  ruled  that  this  -  a  an  acceptable  behavior. 

C55316A  maxes  use  of  an  enumeration  representation  clause 
containing  noncontiguous  values  which  is  not  supported  by  tr.is 
co.mpi  ler . 

C86001F  redefines  package  SYSTEM,  but  TEXT_IO  is  made  obsolete  by 
tnis  new  definition  in  this  implementation  and  the  test  cannot  be 
executed  since  the  package  REPORT  is  dependent  on  the  package 
TE0CT_I0. 

C87B62B  uses  a  length  clause  which  is  not  supported  by  this 
compiler.  The  'STORAGE_SIZE  length  clause  for  access  types  is 
rejected  during  compilation. 

C92005B  is  inapplicable  because  in  this  implementation  a  task's 
STORAGE_SIZE  attribute  yields  a  value  greater  than 
STANDARD. INTEGER ' LAST. 

C96005B  checks  implementations  for  which  the  smallest  and  largest 
values  in  type  DURATION  are  different  from  the  smallest  and 
largest  values  in  DURATION'S  base  type.  This  is  not  the  case  for 
this  implementation. 

BA1011C,  CA1012A,  CA2009C,  CA2009F,  BC3205D,  LA5008M,  and  LA5003N 
compile  generic  declarations  and  bodies  in  separate  compilation 
units.  Separate  compilation  of  generic  bodies  without 
speci fications  is  not  supported  by  this  implementation. 

AE2101C,  CE2201D,  and  CE2201E  use  an  instantiation  of  package 
SEQUENT1AL_I0  with  unconstrained  array  types  which  is  not 
supported  by  this  compiler. 

AE2101H  and  CE2401D  use  an  instantiation  of  package  DIRECT_IO  with 
unconstrained  array  types  which  is  not  supported  by  this  compiler. 

CE2107B..E  (4  tests),  CE2110B,  CE2111H,  CE3111B..E  (4  tests),  and 
CE3114B  are  inapplicable  because  multiple  internal  files  cannot  be 
associated  with  the  same  external  file  except  for  reading.  The 
proper  exception  is  raised  when  multiple  access  is  attempted. 

CE2102D,  CE2102I,  CE2105A,  and  CE2407A  create  a  file  with  mode 
IN_FILE  which  is  not  supported  by  this  implementation. 

CE211 ID  and  CE3115A  create  a  file  with  mode  0UT_FILE,  reset  the 
file  to  mode  IN_FIL£,  and  then  try  to  open  the  file  again  in  mode 
IN_FILE.  This  implementation  retains  the  file's  access  rights 
from  when  it  is  opened  until  the  file  is  closed.  When  a  file  is 
created  with  mode  OUT_FILE,  this  implementation  prohibits  multiple 
access  to  this  file  until  it  is  closed.  When  the  test  resets  the 
file  to  mode  IN_FILE  and  attempts  to  open  a  second  internal  file 
to  the  same  external  file,  this  implementation  raises  USE_ERROR. 
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This  behavior  has  been  determined  to  be  acceptable  by  the  AVO. 

IE3635A  writes  about.  530  characters  to  a  line  in  a  text  file. 
Tnis  implementation  raises  USE_ERR0R  because  this  is  longer  than 
the  acceptable  line  length  imposed  by  the  operating  system  for 
tnis  file  type.  This  implementation  raises  USE_£RK0R  on  the 
subsequent  NEW_LINE,  which  is  when  they  physically  try  to  write 
the  line  to  the  file.  The  issue  will  be  raised  before  the  LMP 
(AI-00534),  and  the  AVO  has  provisionally  ruled  that  this  behavior 
is  acceptable.  When  the  form  parameter  (FORM  =>  "FILE_TYPE=R , 
RECORDLEN=500" )  was  added  to  the  test,  the  implementation  passes 
tne  test  objective. 

The  following  158  tests  require  a  floating-point  accuracy  that 
exceeds  the  maximum  of  16  supported  by  the  implementation: 


C241 13M. .Y 

(13 

tes  ts ) 

C35705M. .Y 

(13 

tests) 

C35706M. .Y 

(13 

tests) 

C35707M. .Y 

03 

tests ) 

C35708M.  .Y 

(13 

tests) 

C358oai.  .Y 

(13 

tests) 

C45241M. .Y 

(13 

tests) 

C45321M. .Y 

(13 

tests ) 

C45421M. .Y 

(13 

tests) 

C45424M. .Y 

(13 

tests) 

C45521M..Z 

(14 

tests) 

C45621M. .Z 

(14 

tests ) 

3.6  SPLIT  TESTS 

If  one  or  more  errors  do  not  appear  to  have  been  detected  in  a  Class  B  test 
because  of  compiler  error  recovery,  then  the  test  is  split  into  a  set  of 
smaller  tests  that  contain  the  undetected  errors.  These  splits  are  then 
compiled  and  examined.  The  splitting  process  continues  until  all  errors 
are  detected  by  the  compiler  or  until  there  is  exactly  one  error  per  split. 
Any  Class  A,  Class  C,  or  Class  E  test  that  cannot  be  compiled  and  executed 
because  of  its  size  is  split  into  a  set  of  smaller  subtests  that  can  be 
processed . 

Splits  were  required  for  35  Class  B  tests: 


B22003A 

824005A 

B33301A 

351003A 

B22004A 

B240053 

E35101A 

B55A01A 

B22004B 

B24204A 

B36201A 

36400 1 A 

B22004C 

B24204B 

B37201A 

367001A 

B23004A 

B26002A 

B37307B 

B67001B 

B23004B 

B29001A 

338008A 

B67001C 

32400  1A 

B2AC03A 

B41202A 

B67001D 

B24001B 

B2AC03B 

B44001A 

B91003B 

B24001C 

B2AC033 

B45205A 
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TEST  INFORMATION 


3.7. 1  ?reval*cation 

Prior  to  validation,  a  set  of  test  results  for  ACVC  Version  1.8  produced  by 
the  Tandem  Ada  Compiler  was  submitted  to  the  AVF  by  the  applicant  for 
review.  Analysis  of  these  results  demonstrated  that  the  compiler 
successfully  passed  ail  applicable  tests,  and  that  the  compiler  exhibited 
the  expected  behavior  on  all  inapplicable  tests. 


3.7.2  Test  Method 

Testing  of  the  Tandem  Ada  Compiler  using  ACVC  Version  1.8  was  conducted 
on-site  by  a  validation  team  from  the  AVF.  The  configuration  consisted  of 
a  Tandem  Nonstop  VLX  operating  under  GUARDIAN  90,  Version  COO. 

A  magnetic  tape  containing  all  tests  except  for  withdrawn  tests  and  tests 
requiring  unsupported  floating-point  precisions  was  taken  on-site  by  the 
validation  team  for  processing.  Test3  that  make  use  of 
implementation-specific  values  were  customized  before  being  written  to  the 
magnetic  tape.  Tests  requiring  splits  during  the  prevalidation  testing 
were  included  in  their  split  form  on  the  magnetic  tape. 

The  contents  of  the  magnetic  tape  were  loaded  directly  onto  the  Tandem 
Nonstop  VLX,  Version  B40  computer  and  read  using  a  special  program  written 
by  Thndem  for  reading  ANSI  tape  format.  The  files  were  then  written  to 
tape  using  tandem  backup  format  and  transferred  to  the  Tandem  NonStop  VLX, 
Version  COO  computer.  After  the  test  files  were  loaded  to  disk,  the  full 
set  of  tests  was  compiled  on  the  Tandem  NonStop  VLX,  and  all  executable 
tests  were  linked  and  run  on  the  Tandem  NonStop  VLX  using  four  parallel 
batch  streams.  Results  were  put  on  tape,  using  standard  Tandem  utilities. 
A  special  Ada  program  was  used  to  print  hard  copies  of  the  results.  The 
results  were  printed  using  any  system  that  had  available  printer  resources. 

The  compiler  was  tested  using  command  scripts  provided  by  Tandem  Computers 
and  reviewed  by  the  validation  team. 

Tests  were  compiled,  linked,  and  executed  (as  appropriate)  using  a  single 
host  and  target  computer.  Test  output,  compilation  listings,  and  job  logs 
were  captured  on  magnetic  tape  and  archived  at  the  AVF.  Tne  listings 
examined  on-site  by  the  validation  team  were  also  archived. 


3.7.3  Test  Site 

The  validation  team  arrived  at  Tandem  Computers,  Cupertino  CA  on  lb  May 
1967,  and  departed  after  testing  was  completed  on  20  May  1987. 
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Tandem  Computers  has  submitted  the  following 
declaration  of  conformance  concerning  the  Tandem  Ada 
Compiler. 
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DECLARATION  OF  CONFORMANCE 


Compiler  Implementor:  Tandem  Computers  Incorporated  (Tandem  Computers) 
Ada'®  Val  idat  ion  Facility:  ASD/SCOL,  Wr  ight-Patterson  AFBr  OH 
Ada  Compiler  Validation  Capability  (ACVC)  Version:  1.8 


Base  Configuration 

Base  Compiler  Name:  Tandem  Ada  Compiler  Version:  Release  T9270C00 
Host  Architecture  ISA:  Tandem  Nonstop  TM  VLX 
OS&VER  #1:  GUARDIAN  90,  Version  COO 
Target  Architecture  ISA:  Tandem  NonStop  TM  VLX 
OS&VER  #1:  GUARDIAN  90,  Version  COO 


Implementor's  Declaration 


I,  the  undersigned,  representing  Tandem  Computers,  have  implemented  no 
deliberate  extensions  to  the  Ada  Language  Standard  ANSI/MIL-STD-1815A 
in  the  compiler  listed  in  this  declaration.  I  declare  that  Tandem 
Computers  is  the  owner  of  record  of  the  Ada  language  compiler  listed 
above  and,  as  such,  is  responsible  for  maintaining  said  compiler  in 
conformance  to  ANSI/MIL-STD-1815A.  All  certificates  and  registrations 
for  Ada  language  compiler  listed  in  this  leclaration  shall  be  made 
only  in  the  owner's  corporate  name. 

J.  7/K/  rate:  £7^7 

Computers '  J\ 

Dennis  McEvoy,  Vice  F(r^sident 
Software  Development 


Owner's  Declaration 


I,  the  undersigned,  representing  Tandem  Computers,  take  full 
responsibility  for  implementation  and  maintenance  of  the  Ada  compiler 
listed  above,  and  agree  to  the  public  disclosure  of  the  final 
Validation  Summary  Report.  I  further  agree  to  continue  to  comply 
with  the  Ada  trademark  policy,  as  defined  by  the  Ada  Joint  Program 
Office.  I  declare  that  oil  of  the  Ada  language  compilers  listed,  and 
their  host/target  performance  are  in  compliance  with  the  Ada  Language 
Standard  ANSI/MIL-STD-1815A. 


Tandem  Comput 
Dennis  McEvoy,  Vice  Pi/dsident 
Software  Development  ^ 


Date :  Sj/jljj 


®Ada  is  a  registered  trademark  of  the  United  States  Government 
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The  only  allowed  implementation  dependencies  correspond  to  implementation- 
dependent  pragmas,  to  certain  machine-dependent  conventions  as  mentioned  in 
chapter  13  of  MIL-STD-1315A,  and  to  certain  allowed  restrictions  on 
recresentation  clauses.  The  implementation-dependent  characteristics  of 
the  Tandem  Ada  Compiler,  Release  TS270C00,  are  described  in  the  following 
sections  which  discuss  topics  in  Appendix  F  of  the  Ada  Language  Reference 
Manual  ( ANSI/MIL-STD- 18 1 5A) .  Implementation-specific  portions  of  the 
pacA3ge  STANDARD  are  also  included  in  this  appendix. 
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APPENDIX  F 

IMPLEMENTATION-DEPENDENT  CHARACTERISTICS 

This  appendix  contains  the  Tandem  implementation  dependencies  for 
Ada  programming.  It  is  also  Appendix  F  for  the  ANSI  Reference 
Manual  for  the  Ada  Programming  Language  (ANSI/MIL-STD-1B15A, 
January  1983).  That  manual  does  not  include  this  appendix,  which 
appears  only  in  this  user's  guide. 

The  implementation  dependencies  this  appendix  describes  include 
•the  following: 

•  The  form,  allowed  places,  and  effects  of  all  implementation- 
dependent  pragmas 

•  The  names  and  types  of  all  implementation-dependent  attributes 

•  The  specification  of  the  package  SYSTEM 

•  Implementation-defined  aspects  of  the  package  STANDARD 

•  Implementation-defined  predefined  packages 

•  Restrictions  on  representation  clauses 

•  Semantics  of  representation  attributes 

•  Restrictions  on  unchecked  conversions 

•  Information  on  input  and  output  features 

•  Information  about  parameters  and  function  returns  for  external 
subprograms 

•  Rules  for  compiling  generic  units 

•  Implementation-defined  limits 
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PRAGMAS 


Tandem  Ada  includes  an  implementation-defined  pragma  and  has 
restrictions  on  several  predefined  pragmas.  This  subsection 
lists  the  additional  pragma  and  the  pragmas  that  have 
restrictions,  with  descriptions. 

For  information  about  using  pragmas,  see  sections  3  and  8.  For 
complete  information  about  predefined  pragmas  for  which  Tandem 
Ada  has  no  restrictions,  see  the  ANSI  Reference  Manual  for  the 
Ada  Programming  Language. 


Implementation-Defined  Pragma 

The  EXTERNAL_NAME  pragma,  which  is  implementation-defined, 
associates  a  TAL  procedure  name  with  the  last  Ada  subprogram 
declared  before  the  pragma  in  the  source  file.  EXTERNAL_NAME 
takes  two  arguments:  the  simple  name  of  an  Ada  subprogram  and  a 
string.  You  can  use  this  pragma  at  the  place  of  a  declarative 
item. 

The  pragma  must  apply  to  the  last  subprogram  declared  before  the 
pragma  in  the  same  declarative  part  or  package  specification. 

You  can  not  use  this  pragma  for  a  library  unit.  The  string  is 
the  TAL  name  of  the  subprogram. 

The  second  argument  to  EXTERNAL  NAME  should  not  start  with  RSL~ 
because  the  compiler  reserves  all  external  subprogram  names 
starting  with  RSL~  for  run-time  support  routines.  If  the  second 
I  argument  does  start  with  RSL~,  the  compiler  issues  a  warning 
I  message. 
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Restrictions  on  Predefined  Pragmas 


The  following  list  summarizes  the  restrictions  on  predefined 
pragmas  for  the  Tandem  Ada  compiler: 

CONTROLLED  This  pragma  has  no  effect.  Everything  is 

controlled. 


INLINE 


This  pragma  has  the  following  effects: 

It  allows  the  compiler  to  expand  subprogram 
calls  in  line. 


If  the  compiler  does  not  expand  a  subprogram 
call  in  line  when  the  latest  compilation  of 
the  subprogram  specification  included  the 
INLINE  pragma,  then  the  compiler  issues  one 
of  the  following  warning  messages  at  each 
call  site: 


The  call  to  this  Inline  subprogram  is  not 
expanded  because  its  body  is  not  available. 


The  call  to  this  Inline  subprogram  is  not 
expanded  because  its  return  type  is 
unconstrained. 


The  call  to  this  Inline  subprogram  is  not 
expanded  because  it  is  either  recursive 
or  mutually  recursive. 


An  in-line  expansion  of  a  subprogram  call 
creates  a  compilation  dependency  on  the  body 
of  the  called  subprogram. 

If  you  do  not  specify  the  INLINE  pragma  for 
a  subprogram,  the  compiler  might  expand  that 
subprogram  call  in  line  if  the  expansion  does 
not  create  any  compilation  dependencies  and 
if  you  use  the  OPTIMIZE  switch  for  the 
compilation.  The  effect  of  the  optimize 
switch  is  an  average  of  the  effects  of  the 
SPACE  and  TIME  settings  of  pragma  INLINE. 

The  compiler  does  not  expand  calls  to  derived 
subprograms . 


The  compiler  can  expand  a  call  to  a  recursive 
subprogram.  However,  the  compiler  does  not 
expand  the  subprogram's  second  call  to  itself. 
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INTERFACE 


MEMORY_SIZE 

OPTIMIZE 


The  only  language  you  can  specify  is  TAL.  An 
Ada  program  can  call  a  TAL  procedure  only  if 
the  procedure  could  have  a  le.al  Aca  sub¬ 
program  specification.  This  means  an  Ada 
program  cannot  call  any  TAL  function  that  has 
an  out  parameter  or  any  TAL  procedure  that  has 
optional  parameters. 

You  cannot  specify  the  INTERFACE  pragma  for 
renamed  subprograms  or  library  subprograms. 

Without  a  corresponding  pragma  EXTERNAL_NAME , 
the  subprogram  name  in  the  INTERFACE  pragma 
must  be  the  same  as  the  TAL  procedure  name. 

A  TAL  procedure  for  an  Ada  procedure  cannot 
have  a  return  value,  and  a  TAL  procedure  for 
an  Ada  function  must  have  a  return  value. 

This  pragma  is  reserved  for  development  use 
in  compiling  the  base  library. 

This  pragma  does  not  apply  to  any  block  or 
body  nested  within  the  block  or  body  whose 
declarative  part  contains  the  pragma.  This 
gives  you  greater  control  because  you  can 
specify  the  OPTIMIZE  pragma  for  individual 
nested  blocks  or  bodies  when  you  want  to.  You 
can  specify  the  OPTIMIZE  pragma  at  mere  than 
one  place  in  a  declarative  part. 

If  you  do  not  specify  the  OPTIMIZE  switch  in 
the  ADA  command  for  a  compilation,  the 
compiler  does  not  expand  subprogram  calls 
in  line  unless  a  pragma  INLINE  applies  to  the 
subprogram.  If  you  do  specify  the  OPTIMIZE 
switch  in  the  ADA  command,  the  compiler  might 
expand  other  subprogram  calls  in  line  where 
the  expansion  does  not  create  additional 
compilation  dependencies.  The  OPTIMIZE  pragma 
provides  additional  control  over  when  the 
compiler  performs  in  line  expansion.  • 

This  pragma  takes  one  parameter,  either  SPACE 
or  TIME.  If  you  specify  SPACE,  then  in-line 
expansion  happens  only'  where  it  does  not 
increase  the  generated  code  size.  If  you 
specify  TIME,  in-line  expansion  might  occur 
more  often  for  subprograms  of  moderate  size. 
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If  you  do  not  specify  the  OPTIMIZE  pragma,  the 
effect  is  in  between  the  results  from  SPACE 
and  TIME.  If  you  specify  the  pragma  more  than 
once  for  a  ur.it  of  code  using  SPACE  in  one 
instance  and  TIME  in  another,  the  effect  is 
the  same  as  if  you  did  not  specify  the  pragma. 

This  pragma  has  no  effect  on  data  layout.  If 
you  use  this  pragma,  the  compiler  issues  a 
warning  message. 

This  pragma  is  reserved  for  development  use 
in  compiling  the  base  library. 

This  pragma  has  no  effect  on  the  suppression 
or  generation  of  checking  code.  If  you  use 
this  pragma,  the  compiler  issues  a  warning 
message. 

This  pragma  is  reserved  for  development  use 
in  compiling  the  base  library. 


ATTRIBUTES 


Tandem  Ada  has  no  implementation-defined  attributes.  For  the 
semantics  of  predefined  attributes,  see  "Representation 
Attributes,"  later  in  this  appendix. 


PREDEFINED  PACKAGES 


In  addition  to  the  packages  SYSTEM  and  STANDARD  and  the  standard 
input-output  packages,  Tandem  Ada  has  predefined  packages  for 
Nonstop  systems: 

•  COMMAND_INTERPRETER_INTERFACE,  which  reads  the  startup, 
assign,  and  param  messages  for  the  Ada  process.  It  also 
provides  procedures  and  functions  that  the  process  can  use  to 
get  information  from  these  messages. 

•  SYSTEM_CALLS,  which  enables  Ada  programs  to  set  completion 
codes  .~ 
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Package  SYSTEM 


The  specification  of  package  SYSTEM  for  the  Tandem  Ada  compiler 
on  Nonstop  systems  follows: 

package  SYSTEM  is 

type  ADDRESS  is  private; 

type  NAME  is  (NONSTOP); 


SYSTEM  NAME  :  constant  NAME  :»  NONSTOP; 


STORAGE_UNIT  :  constant 
MEMORY_S I ZE  :  constant  :■ 

—  System-dependent  named 

MIN_INT  :  constant  :* 

MAX_INT  :  constant  :« 

MAX_DIGITS  :  constant 
MAX_MANT I SS A  :  constant  :* 
FINE  DELTA  :  constant  : * 


TICK  :  constant  :* 

—  Other  system-dependent 


8; 

2  **  30; 
numbers : 

-9_223_372_036_854_775  808; 
+9  223_372_036  854  775  807; 
16; 

31; 

2.0  **  (-31); 


0.01; 

declaration: 


subtype  PRIORITY  is  INTEGER  range  0  ..  -1; 
private 


end  SYSTEM; 
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Package  STANDARD 


In  the  predefined  package  STANDARD,  each  implementation  defines 
the  number  of  predefined  numeric  types,  their  names,  and  their 
representation  attributes. 

Tandem's  Ada  compiler  supports  the’ following  predefined  numeric 
types : 

type  SHORT_ INTEGER  is  range  -2  **  7  ..  2  **  7  -  1; 
for  SHORT_ INTEGER' SIZE  use  8; 

type  INTEGER  is  range  -2  **  15  ..  2  **  15  -  1; 
for  INTEGER' SIZE  use  16; 

type  LONG_ I NTEGER  is  range  -2  **  31  ..  2  **  31  -  1; 
for  LONG_TNTEGER 'SIZE  use  32; 

type  LONG  LONG_INTEGER  is  range  -2  **  63  ..  2  **  63  -  1; 
for  LONG_LONG_ I NTEGER’ SIZE  use  64; 

type  FLOAT  is  digits  6  range  -(2  **  254  *  (1  -  2  **  (-21)))  .. 

2  **  254  *  (1  -  2  **  (-21) ) ; 

—  range  is  -FLOAT ' SAFE_LARGE  ..  FLOAT ' SAFE_LARGE 
for  FLOAT' SIZE  use  32; 

type  LONG_FLOAT  is  digits  16 

range  -(2  **  254  *  (1  -  2  **  (-55)))  .. 

2  **  254  *  (1  -  2  **  (-55)); 

--  range  is  -LONG_FLOAT ' SAFE_LARGE  ..  LONG_FLOAT ' SAFE_LARGE 
for  LONG_FLOAT'SIZE  use  64; 

type  DURATION  is  delta  1  /  2  **  14 

range  -(2  **  31  /  2  **  14) 

(2  *•  31  -  1)  /  2  **  14; 
for  DUR/.T  I  ON  'SIZE  use  64; 

for  BOOLEAN ' S I ZE  use  8; 

for  CHARACTER' SIZE  use  8; 
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Package  COMMAND  INTERPRETER  INTERFACE 


The  COMMAND_ I NTERPRETER_ INTERFACE  package  enables  an  Ada  process 
to  communicate  with  an  operating  system  command  interpreter. 

The  specification  for  this  package  follows,  with  comments  that 
describe  the  information  Ada  processes  can  get  from  the  command 
interpreter . 

package  COMMAND_INTERPRETER_I NTERFACE  is 

This  package  reads  the  startup,  assign,  and  param 
messages  and  returns  the  specified  information  from 
these  messages.  For  details  about  the  interface  to 
the  operating  system  command  interpreter,  see  the 
GUARDIAN  Operating  System  Programmer's  Guide. 

Elaboration  code  in  this  package  reads  the  command 
interpreter  messages.  To  use  this  package  in  the 
elaboration  of  another  compilation  unit,  the  dependent 
unit  should  specify  pragma  ELABORATE  for  this  package. 

CANT_READ_MESSAGES  s  exception; 

—  Raised  by  all  routines  if  the  Ada  process  could  not 

—  read  the  command  interpreter  messages. 

FlELD^NOT_PRESENT  :  exception; 

—  Raised  when  a  field  selection  of  an  assign  message  is 

—  absent. 

type  ASS  I GN_MESSAGE_T  is  private; 

NOASSIGN  :  constant  ASSIGN  MESSAGE  T; 


type  F I LE_EXCLL’S ION_T  is  (SHARED,  EXCLUSIVE,  PROTECTED); 

type  FILE_ACCESS_T  is  (IN_OUT,  INPUT,  OUTPUT); 

subtypt  LOGICAL_FILENAME_T  is  STRING  (1  ..  31); 

type  PARAM_MESSAGE_T  is  private; 

NO_PARAM  ;  constant  PARAM_MESSAGE_T; 

function  GET_DEFAULT  return  STRING; 

--  Returns  the  default  volume  and  subvolume  specified  by 
--  the  startup  message  in  the  form  "$VOL.SUBVOL" . 
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function  GET  INFILE  return  STRING; 

--  Returns  tHe  IN  file  specified  by  the  startup  message  i 

--  in  the  form  " $VOL . SUB VOL . DNAME" . 

function  GET  OUTFILE  return  STRING; 

--  Returns  tKe  OUT  file  specified  by  the  startup  i 

--  message  in  the  form  " Z VOL. SUBVOL. DNAME". 

function  GET  STARTUP_MESSAGE_i_PARAM  return  STRING; 

--  Returns  tHe  parameter  string  specified  in  the  RUN 
--  command  line  from  the  startup  message.  The  returned 

—  string  does  not  include  any  trailing  null  characters 
--  with  which  the  command  interpreter  padded  the  string. 

procedure  ASSIGN  LIST_RESET; 

--  Resets  the  pointer  to  the  first  assign  message. 

function  GET  NEXT_ASSIGN  return  ASS I GN_MESSAGE_T ; 

--  Returns  tHe  next  message  from  the  assign  message  list 

—  or,  if  no  message  is  left,  returns  NO_ASSIGN. 

function  SEARCH_ASS I GN  ( PROG_NAME  :  in  STRING; 

F I LE_NAME  :  in  STRING) 
return  ASS I GN_MESSAGE  T; 

--  Searches  the  list  of  assign  messages  for  tHe  logical  unit 
--  specified.  A  match  occurs  when  both  the  input  program 
name  and  file  name  are  identical  to  those  of  an  assign 

—  message.  Otherwise,  the  function  returns  NO_ASSIGN. 

procedure  GET_LOG I CAL_UN I T_NAMES  (ASSIGN  ;  in  ASS I GN_MESS AGE_T ;  I 

PROG_NAME  ;  out  LOG I CAL_F I LENAME_T ; 
PROG_NAME_LEN  :  out  INTEGER; 

FILE  NAME  :  out  LOG  I CAL_F I LENAME_T ; 
FILE~NAME  LEN  ;  out  INTEGER); 

--  Returns  the  program  name  and  file  names  of  the  logical 

—  unit  for  the  specified  assign  message. 

function  IS  TANDEM_F I LENAME_PRESENT 

”(ASSIGN  ;  ASS  I GN_MESS AGE_T )  return  BOOLEAN; 

--  Returns  TRUE  if  the  operating  system  file  name  is  present  or 

—  FALSE  otherwise. 

function  I S_PR I _EXTENT_P RE S ENT  (ASSIGN  :  ASS I GN_MESSAGE_T ) 

return  BOOLEAN;- 

—  Returns  TRUE  if  the  primary  extent  is  present  or  FALSE 

—  otherwise. 
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function  I S_SEC_EXTENT_PRESENT  (ASSIGN  :  ASS  I GN_MESSAGE_T ) 

return  BOOLEAN; 

--  Returns  TRUE  if  the  secondary  extent  is  present  or  FALSE 
--  otherwise. 

function  I S_F I LECODE_PRESENT  (ASSIGN  :  ASS IGN_MESSAGE_T ) 

return  BOOLEAN; 

--  Returns  TRUE  if  the  file  code  is  present  or  FALSE 
--  otherwise. 

function  IS_EXCLUSION_PR£SENT  (ASSIGN  :  ASS  I GN_MESSAGE_T ) 

return  BOOLEAN; 

—  Returns  TRUE  if  the  exclusion  spec  is  present  or  FALSE 
--  otherwise. 

function  IS_ACCESS_SPEC_PRESENT  (ASSIGN  :  ASS I GN_MESSAGE_T ) 

return  BOOLEAN; 

--  Returns  TRUE  if  the  access  spec  is  present  or  FALSE 
--  otherwise. 

function  IS_R£CORD_SIZE_PRESENT  (ASSIGN  :  ASS I GN_MESS AGE_T ) 

return  BOOLEAN; 

—  Returns  TRUE  if  the  record  size  is  present  or  FALSE 

—  otherwise. 

function  IS_BLOCK_SIZE_PRESENT  (ASSIGN  :  ASS IGN_MESSAGE_T ) 

return  BOOLEAN; 

—  Returns  TRUE  if  the  block  size  is  present  or  FALSE 

—  otherwise. 

function  GET_TANDEM_F I LENAME  (ASSIGN  :  ASS  I GN_MESS AGE_T ) 

return  STRING;  ~ 

—  Returns  the  operating  system  file  name  for  the  specified 

—  assign  message.  Absence  of  the  field  raises 
--  F I ELD_NOT_PRESENT . 

function  GET_PR I _EXTENT  (ASSIGN  ;  ASS  I GN_MESSAGE_T ) 

return  INTEGER; 

—  Returns  the  primary  extent  for  the  specified  assign 

--  message.  Absence  of  the  field  raises  FIELD_NOT_PRESENT . 

function  GET_SEC_EXTENT  (ASSIGN  ;  ASS  I GN_MESSAGE_T ) 

return  INTEGER; 

—  Returns  the  secondary  extent  for  the  specified  assign 

—  message.  Absence  of  the  field  raises  FIELD_NOT_PRESENT. 

function  GET_F I LECODE  (ASSIGN  :  ASS IGN_MESSAGE_T ) 

return  INTEGER;- 

—  Returns  the  file  code  for  the  specified  assign  message. 
--  Absence  of  the  field  raises  FIELD  NOT  PRESENT. 
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function  GET  EXCLUSION  (ASSIGN  :  ASS  I GN_MESS AGE_T ) 

return  FILE  EXCLUSION_T; 

--  Returns  the  exclusion  spec  for  tTie  specified  assign 
--  message.  Absence  of  the  field  raises  F I ELD_NOT_PRESENT . 

function  GET_ACCESS_SPEC  ( ASSIGN  :  ASS I GN_MESSAGE_T ) 

return  F I LE_ACCESS_T ; 

--  Returns  the  access  spec  for  the  specified  assign 
--  message.  Absence  of  the  field  raises  FI ELD_NOT_PRESENT . 

function  GET_RECORD_S I 2E  (ASSIGN  :  ASS I GN_MESSAGE_T ) 

return  INTEGER;- 

--  Returns  the  record  size  for  the  specified  assign 
--  message.  Absence  of  the  field  raises  FIELD_NOT_PR£SENT. 

function  GET_BLOCX_SIZE  (ASSIGN  :  ASS  I GN_MESSAGE_T ) 

return  INTEGER; 

--  Returns  the  block  size  for  the  specified  assign  message. 

—  Absence  of  the  field  raises  F I ELD_NOT_PRESENT . 

procedure  PARAM_LIST_RESET; 

—  Resets  the  pointer  to  the  beginning  of  the  param 

—  message  list. 

function  GET  NEXT_PARAM  return  PARAM_MESSAGE_T; 

—  Returns  tKe  next  message  from  the  param  message  list  or, 

—  if  no  message  is  left,  returns  NO_F ARAM. 

function  SEARCH_PARAM_L I ST  (NAME  ;  STRING) 

return  PARAM_MESSAGE^T; 

—  Searches  the  param  message  list  for  a  param  wTth  the 

--  specified  name  and  returns  the  message  for  the  param  that 

—  matches.  If  none  matches,  it  returns  NO_P ARAM . 

function  GET_PARAM_NAME  (PARAM  :  PARAM_MESSAGE_T ) 

return  STRING; 

--  Returns  the  param  name  of  the  specified  param  message. 

function  GET_PARAM_VALUE  (PARAM  ;  PARAM_MESS AGE_T ) 

return  STRING; 

—  Returns  the  value  of  the  specified  param  message, 
private 


end  COMMAND_INTERPRETER_INTERFACE; 
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Package  SYSTEM  CALLS 


The  predefined  package  SYSTEM_CALLS  enables  Ada  programs  to 
set  completion  codes.  The  Ada  process  can  either  exit  while 
setting  the  completion  code  information  or  set  the  completion 
code  information  to  be  used  when  the  process  reaches  its  normal 
termination. 

The  package  contains  six  subprogram  declarations  for  operating 
system  procedures,  two  each  for  the  ABEND,  SETCOMPLETIONCODE , 
and  STOP  procedures.  For  each  procedure,  you  can  have  your  Ada 
program  set  only  the  completion  code  parameter  or  set  the  five 
supplemental  information  parameters  as  well  as  the  completion 
code  parameter.  For  information  about  the  completion  code 
parameter  and  the  supplemental  information  parameters,  see  the 
System  Procedure  Calls  Reference  Manual. 

If  an  unhandled  exception  reaches  the  main  subprogram,  an  Ada 
process  returns  the  completion  code  5,  whether  or  not  the  Ada 
program  set  a  different  code. 

If  an  Ada  process  terminates  without  calling  any  of  the  subpro¬ 
grams  in  the  SYSTEM_CALLS  package,  the  process  returns  the 
completion  code  0  for  normal  termination  of  the  main  subprogram. 
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The  specification  for  the  package  SYSTEM_CALLS  follows. 


Package  Na.~e  :  SYSTEM_CALLS 

Purpose  :  Ada  interface  to  operating  system  procedures 


package  SYSTEM_CALLS  is 

type  COMPLET I ON_CODE  is  new  INTEGER; 

subtype  TAND£M_COMPLETION_CODE  is  COMPLET I ON_CODE 

range  -32767  . .  -1 ; 

subtype  SHARED_COMPLETION_CODE  is  COMPLET I ON_CODE 

range  0  ..  999; 

subtype  CUSTOMER_COMPLETION_CODE  is  COMPLET I ON_CODE 

range  1000  ..  32767; 

constant  S H ARED_COMP LET I ON_CODE  :*  0; 
constant  SHARED_COMPLET I ON_CODE  1; 
constant  SHARED_COMPLET I ON_CODE  :«=  2; 
constant  S HARED~COMPLET I ON_CODE  :=  3; 
constant  SHAR£D~COMPLET I ON_CODE  :*  5; 
WARNING  EXAMINE  :  constant  SHARED  COMPLETION  CODE  :=  8; 


NORMAL 

WARNING 

FATAL 

PREMATURE 

ABNORMAL 


Subprogram  Name;  ABEND 

Purpose;  Ada  interface  to  the  operating  system 
procedure  ABEND 


procedure  ABEND  (COMPL_CODE  ;  COMPLET I ON_CODE) ; 

pragma  INTERFACE  (TAL,  ABEND); 

pragma  EXTERNAL  NAME  (ABEND,  " Rs 1 ^ Abend 1" ) ; 


procedure  ABEND  (COMPL_CODE 

TERMINATION  INFO 
SUBSYS  ORG 
SUBSYS~NUM 
SUBSYS~VER 
TEXT 

pragma  INTERFACE  (TAL,  ABEND); 
pragma  EXTERNAL  NAME  (ABEND,  "Rsl'' 


;  COMPLET I ON_CODE; 
;  INTEGER; 

:  STRING; 

:  INTEGER; 

;  STRING; 

;  STRING); 

Abend2" ) ; 
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Subprogram  Name:  SET_COMPLETION_CODE 

Purpose:  Ada  interface  to  set  the  completion  cede  to  be 

used  when  the  process  stops 


procedure  SET_COMPLETION_CODE  ( COMPL_CODE  :  COMPLETION  CODE); 
pragma  INTERFACE  (TAL,  SET_COMPLETION  CODE); 
pragma  EXTERNAL_NAME  (SET  COMPLETION_CODE , 

"RsT''Set^'Completion''Codel"  )  ; 


procedure  SET_COMPLET ION_CODE  (COMPL_CODE  : 

TERM I NAT  I ON_ INFO  : 
SUBSYS  ORG  : 

SUBSYS~NUM  : 

SUBSYS_VER  : 

TEXT  : 

pragma  INTERFACE  (TAL,  SET_COMPLETION_CODE) ; 
pragma  EXTERN AL_NAME  (SET  COMPLETION_CODE, 

”RsT^Set~Completion^Code2" ) 


COMP LET I ON_CODE ; 
INTEGER; 

STRING; 

INTEGER; 

STRING; 

STRING) ; 


Subprogram  Name:  STOP 

Purpose:  Ada  interface  to  the  operating  system 

procedure  STOP 


procedure  STOP  (COMPL_CODE  :  COMPLETION_CODE ) ; 

pragma  INTERFACE  (TAL,  STOP); 

pragma  EXTERNAL_NAME  (STOP,  "Rsl^Stopl" ) ; 


procedure  STOP  (COMPL_CODE 

TERM I NAT I 0N_ I NFO 
SUBSYS  ORG 
SUBSYS~NUM 
SUBSYS_VER 
TEXT 

pragma  INTERFACE  (TAL,  STOP); 
pragma  EXTERN AL_NAME  (STOP,  "Rsl~ 

end  SYSTEM  CALLS; 


:  COMPLET I ON_CODE ; 
:  INTEGER; 

:  STRING; 

;  INTEGER; 

:  STRING; 

:  STRiNG); 

Stop2 " ) ; 
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Package  LOW  LEVEL  10 


The  compiler  also  has  the  predefined  package  LOW_LEVEL_IO,  as 
required  by  the  Ada  standard.  However,  a  call  to  a  subprogram  in 
LOW  LEVEL_IO  does  not  cause  any  input  or  output  operation  to  be 
perTormed. 

The  specification  for  the  predefined  package  LOW_LEVEL_IO 
follows : 


package  LOW_LEVEL_IO  is 


type  DEVICE_TYPE  is  (NO_DEVICE); 
type  DATA_TY?E  is  (NO^DATA); 

procedure  SEND_CONTROL  (DEVICE  :  DEVICE_TYPE; 

DATA  :  in  out  DATA_TYPE) ; 


end 


procedure  RECEI VE_CONTROL 
LOW  LEVEL  10; 


(DEVICE  :  DEVICE_TYPE; 

DATA  ;  in  out  DATA  TYPE); 


A  call  to  either  procedure  in  the  package  alvays  returns  N0_DATA 
to  the  formal  in  out  parameter  DATA.  A  call  to  either  procedure 
has  no  other  effect  at  run  time,  except  for  taking  time  and 
memory. 


i 
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DATA  REPRESENTATION 


This  subsection  defines  how  the  Tandem  Ada  compiler  represents 
data.  It  includes  definitions  of  the  default  data  representation 
of  different  types  and  of  how  representation  clauses  and  repre¬ 
sentation  pragmas  affect  data  layout. 


Default  Data  Representations 


Each  type  has  an  associated  size  and  alignment,  both  expressed  in 
bits.  This  size  and  alignment  is  the  default  data  representation 
for  the  type. 

The  size  specifies  the  size  of  the  container  in  which  the 
compiler  can  store  an  instance  of  the  type.  The  container  size 
for  a  scalar  is  always  8,  16,  32,  or  64  bits.  The  container 
size  for  a  composite  is  always  an  integral  number  of  8-bit  bytes 
greater  than  or  equal  to  0. 

The  default  alignment  of  a  type  specifies  the  alignment  that 
the  compiler  uses  for  objects  of  that  type  in  the  absence  of  a 
representation  clause  to  the  contrary.  The  alignment  is  always 
either  8  or  16  bits. 

Scalar  values  are  always  right  justified  in  their  containers  and 
sign  filled.  That  is,  the  least  significant  bit  of  the  scalar 
value  is  the  least  significant  bit  of  the  container.  Composite 
values  are  always  left  justified  in  their  containers  and  zero 
filled.  That  is,  the  bit  of  the  composite  corresponding  to  at  0 
range  0..0  occupies  the  most  significant  bit  of  the  container. 
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Sizes  the  Compiler  Knows  at  Compile  Time 


To  understand  the  rules  for  record  layout,  the  restrictions 
on  component  clauses,  the  restrictions  on  UNCHECKED_CONVERS ION , 
and  some  of  the  information  in  the  data  map  that  the  compiler 
produces,  you  need  to  know  certain  rules  about  which  sizes  the 
Tandem  Ada  compiler  knows  at  compile  time.  This  subsection 
explains  these  rules. 

The  compiler  can  always  determine  the  sizes  of  the  following  at 
comp.le  time: 

•  Scalar  types  and  subtypes 

•  Access  types  and  subtypes 

•  Task  types  and  subtypes 

For  an  array  subtype,  the  compiler  can  determine  the  size  at 
compile  time  if  it  can  determine  the  size  of  the  component  at 
compile  time  and  if  all  discrete  ranges  are  static. 

For  a  record  subtype,  to  determine  the  size  at  compile  time, 
the  compiler  must  be  able  to  determine  the  sizes  of  all  valid 
components  at  compile  time.  If  the  subtype  is  statically 
constrained,  the  compiler  needs  to  determine  only  the  sizes 
of  valid  components,  and  it  can  use  discriminant  values  to 
figure  out  the  sizes  of  these  components.  For  an  unconstrained 
record,  the  compiler  must  be  able  to  determine  the  sizes  of  all 
components . 

If  an  unconstrained  record  has  any  component  whose  constraints 
come  from  a  discriminant,  the  compiler  cannot  determine  the  size 
of  the  record  at  compile  time. 

If  an  unconst ’ ained  record  has  a  variant  part,  the  compiler 
calculates  the  size  of  the  largest  variant  and  uses  that  to 
compute  the  size  of  the  record. 

For  a  private  type,  the  compiler  can  determine  the  size  at 
compile  time  only  if  it  can  determine  the  private  type's  full 
declaration  size  at  compile  time.  For  a  dynamically  constrained 
record,  the  compiler  cannot  determine  its  size  at  compile  time. 
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Scalar  Types 


Scalar  types  obey  some  common  rules: 

•  Subtypes  always  have  the  same  size  as  their  base  types. 

If  you  want  to  have  a  different  representation,  you  must 
introduce  a  derived  type.  For  example,  if  you  want  to  select 
a  different  size  (via  "for  T'SIZE  use  n"),  you  must  introduce 
a  derived  type. 

•  Tandem  Ada  does  not  perform  biased  arithmetic.  That  is,  the 
integer  value  3  is  always  stored  as  2#11#,  even  for  a  type  T 
for  which  T* FIRST  is  3. 

•  A  scalar  (derived)  type  always  inherits  the  size  of  its  parent 
type. 

These  rules  apply  to  the  following  types: 

•  Integer  types 

•  Enumeration  types 

•  Floating-Point  Types 

•  Fixed-Point  Types 

The  following  subsections  explain  the  default  data  representation 

for  each  of  these  types. 


iMi'^t.y.LKZAZ' :  UN-JEPES'DENT 
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Integer  Types 


Integer  types  are  represented  as  two ’ s-complement  binary  inte¬ 
gers.  The  container  size  for  an  integer  type  is  equal  to 
the  size  of  its  parent  type  unless  a  length  clause  specifies 
a  different  value.  The  compiler  chooses  the  smallest  possible 
container  size  for  the  parent  type. 

Table  F-l  shows  the  sizes  and  alignments  of  the  predefined 
integer  types. 


Table  F-l.  Sizes  and  Alignments  of  Predefined  Integer  Types 


Type 

Size 

Alignment 

SHORT_ INTEGER 

8  bits 

8  bits 

INTEGER 

16  bits 

16  bits 

LONG_I NTEGER 

32  bits 

16  bits 

LONG_LONG_ INTEGER 

64  bits 

16  bits 
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The  alignment  is  8  bits  if  the  size  of  the  type  is  8  bits; 
otherwise,  the  alignment  is  16  bits.  Table  F-2  shows  examples  o 
this . 


Table  F-2.  Relationship  of  Alignment  to  Size 


Type 

Size 

Alignment 

type 

BYTE 

is  range  0  . .  127 ; 

8 

8 

subtype  I 

is  INTEGER  range  -5  ..  14; 

16 

16 

type 

J  is 

range  -5  ..  14; 

8 

8 

type 

S  is 

range  0  ..  2  **  8  -  1; 

16 

16 

type 

U  is 

range  0  ..  2  **  16  -  1; 

32 

16 

type 

2  is  INTEGER  range  VAR1  ..  VAR2 ; 
Varl  and  var2  might  or  might  not 
be  static  integer  expressions. 

16 

16 

type 

x  is 

new  INTEGER  range  1  ..  10; 

16 

16 

type 

Y  is 

new  LONG^INTEGER 
range  1  ..  10; 

32 

16 

type 

W  is 

new  LONG_LONG_ INTEGER 
rangi  1  ..  10; 

64 

16 

Enumeration  Types 


IMPLEMENT  AT  I ON- DEPEND: 
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The  value  of  an  enumeration  literal  is  equal  to  its  position 
represented  as  an  unsigned  quantity.  For  enumeration  types  with 
no  more  than  256  literals,  the  compiler  gives  a  container  size 
of  8  bits  and  an  alignment  of  8  bits  and  treats  the  value  as 
an  unsigned  quantity.  For  enumeration  types  with  more  than  256 
but  fewer  than  32,768  literals,  the  compiler  gives  a  container 
size  of  16  bits  and  an  alignment  of  16  bits  and  treats  the  value 
as  a  signed  quantity.  Tandem  Ada  does  not  support  enumeration 
types  with  more  than  32,767  literals.  Table  F-3  shows  examples 
of  enumeration  types  and  their  sizes  and  alignments,  in  bits. 


Table  F-3.  Sizes  and  Alignments  of  Enumeration  Types 


Type 

Size 

Alignment 

type  BOOLEAN  is  (FALSE,  TRUE); 

8 

8 

type  CHARACTER  is  (...); 

8 

8 

type  Z  is  (El , E2 ,E3 ,E4 , . . . , E300 ) 

16 

16 

type  ALPHA  is  new  CHARACTER 

range  'a'  . .  ' z’ ; 

8 

8 

type  NZ  is  new  Z  range  El  ..  E10 

16 

16 

B-22 


IMPLEMENT AT I  ON - DEPENDENT  CHARACTER I  ST  I CS 
Scalar  Types 


Floating-Point  Types 


The  definitions  for  FLOAT  and  LONG_FLOAT  in  the  package  STANDARD 
and  the  description  of  the  floating-point  hardware  in  the 
Tandem  System  Description  Manual  imply  the  following  values  for 
floating-point  types: 


FLOAT' DIGITS  *  6 
FLOAT 'MANTISSA  -  21 

FLOAT ' EPS  I  LON  *  8#0 . 4000_000#  *  2.0E-21 
FLOAT 'EMAX  -  84 

FLOAT ' SMALL  »  8#0 . 4000_000#  *  2.0E-84 
FLOAT ' LARGE  -  8#0 . 7777_777#  *  2.0E+84 
FLOAT ' SAFE_EMAX  -  254 

I  FLOAT ' SAFE  SMALL  -  8#0.4000  000#  *  2.0E-254 
I 

I  FLOAT ' SAFE_LARGE  -  8#0 . 7777_777#  *  2.0E+254 
FLOAT ' MACH I NE_MANT I SS A  -  23 

LONG_FLOAT' DIGITS  *16 
LONG_FLOAT' MANTISSA  -55 

LONG_FLOAT’ EPSILON  ■  8#0 . 4000_0000_0000_0000_000#  *  2.0E-55 
LONG_FLOAT ’ EMAX  -  220 

LONG_FLOAT ' SMALL  »  8#0 . 4000_0000_0000_0000_000#  *  2.0E-220 
LONG_FLOAT ' LARGE  -  8#0 . 7777_7777_7777_7777_774#  *  2.0E+220 
LONG_FLOAT ' SAFE_EMAX  -  254 

I  LONG_FLOAT ' SAFE_SMALL  -  8#0 . 1000_0000_0000_0000_000#  *  2.0E-254 
I  LONG_FLOAT’ SAFE_LARGE  «  8#0 . 7Z77_7777_7777_7777_774#  *  2.0E+254 
LONG  FLOAT 'MACHINE  MANTISSA  »  55 
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The  following  values  apply  to  both  predefined  floating-point 
types : 

'  MACH  I  NE_EMAX  "=  25C 
' MACHINE_EMIN  -  -255 
' MACH  I NE_RAD I X  -  2 
' MACH  I NE_ROUNDS  *  TRUE 
' MACH I NE_07 ERFLOWS  *  TRUE 

The  representation  sizes  for  floating-point  types  are  32  and  64 
bits  for  FLOAT  and  LONG_FLOAT,  respectively.  The  alignment  is 
16  for  both  types.  FLOAT  is  the  base  type  of  a  user-defined 
floating-point  type  if  the  user-defined  type  has  the  following: 

•  No  more  than  6  digits 

•  If  specified,  a  range  within  the  range  of  the  safe  numbers  of 
FLOAT 

The  format  for  floating-point  data  items  is  the  format  that 
the  Tandem  System  Description  Manual  defines  for  floating-point 
numbers. 
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R 


Fixed-point  types  are  represented  as  signed  integers  equal  to  the 
value  of  sign  *  mantissa  *  small,  which  Section  3.5,9  of  the  ANSI 
Reference  Manual  for  the  Ada  Programming  Language  defines. 

When  you  give  a  fixed-point  type  specification  and  a  'SMALL 
specification,  the  compiler  chooses  a  fixed-point  base  type  with 
that  value  of  'SMALL  and  with  a  mantissa  of  31  bits.  When  you 
do  not  specify  'SMALL,  the  compiler  chooses  a  fixed-point  base 
type  with  a  value  of  'SMALL  that  is  the  largest  power  of  2 
smaller  than  or  equal  to  'DELTA  of  the  type  specification  and 
with  a  mantissa  of  31  bits.  In  either  case,  the  base  type  is 
for  the  fixed-point  subtype  being  defined  by  the  fixed-point  type 
def inition. 

The  size  for  fixed-point  types  is  always  64  bits,  although 
MAX  MANTISSA  is  31.  'SMALL  for  fixed-point  types  must  be  in  the 
following  range: 

2** ( -256 )  to  2**255 

The  range  of  fixed-type  values  follows: 

-2**31  *  2**255  ..  -2** ( -256 )  ,  0,  2**(-256)  ..  (2**31-1)  *  2**255 

If  the  definition  type  T  is  delta  DEL  range  LB  ..  UB  is  in 
effect,  then  all  of  the  following  are  true: 

•  T ' SMALL  ■  T ' BASE ' SMALL  -  T'SAFE_SMALL  »  largest  power  of  2 
less  than  or  equal  to  DEL 

•  T  BASE  MANTISSA  -  31 

•  T' DELTA  «  DEL 

•  T' BASE 'DELTA  «  T’ SMALL 

•  T' BASE 'LARGE  -  T'SAFE_LARGE  -  (2  **  31  -  1)  *  T' SMALL 

•  T'MACHINE_OVERFLOWS  -  TRUE 

•  T ' MACK I NE_ROUNDS  ■  TRUE 

The  range  of  T' BASE  is  -(2  **  31)  *  T' SMALL  ..  2  **  31  *  T ' SMALL . 

Ada  fixed-point  types  do  not  correspond  directly  to  any  type 
in  Tandem's  Transaction  Application  Language  (TAL) .  Also,  the 
values  of  certain  fixed-point  types  cannot  be  represented  as 
floating-point  values  because  the  bounds  of  a  fixed-point  type 
can  be  greater  than  the  bounds  of  the  largest  floating-point 
type.  So,  when  an  Ada  program  passes  a  parameter  of  a  fixed- 
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point  type  to  a  TAL  procedure,  the  TAL  procedure  must  recreate 
the  fixed-point  value,  as  explained  under  "Scalar,  Access,  and 
Constrained  Composite  Parameters"  in  Section  8. 


Array  Types 


The  size  and  alignment  of  an  array  depends  on  the  size  end 
alignment  of  its  components. 

The  compiler  arranges  arrays  so  that  all  components  have  the 
same  size  and  alignment  as  the  component  type,  and  the  entire 
array  has  the  same  alignment.  For  example,  if  an  array  has 
1-byte  components  aligned  to  1-byte  boundaries,  then  the  array 
also  has  1-byte  alignment.  The  stride  of  an  array  is  the  size  of 
each  component  of  the  array — the  difference  between  A(I)' ADDRESS 
and  A(T' SUCC( I ))' ADDRESS) .  The  compiler  stores  multidimensional 
arrays  in  row-major  order. 

The  algorithm  for  calculating  the  size  and  alignment  of  an  array 
follows: 

1.  Set  the  alignment  of  the  array  to  the  alignment  of  the 
component . 

2.  Set  the  stride  to  the  component  size. 

3.  Set  the  size  of  the  array  to  the  product  of  the  stride  and 
the  number  of  elements.  For  unconstrained  array  types,  the 
number  of  elements  is  undefined;  however,  the  size  is  equal 
to  the  maximum  possible  size  that  a  constrained  subtype  could 
have. 
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The  size  and  alignment  of  a  record  depends  on  the  size  and 
alignment  of  its  components  and  any  record  representation  clauses 
and  length  specifications  for  the  record.  The  following  subsec¬ 
tions  describe  the  default  data  representation  for  simple  and 
complex  records,  including  static,  nonvariant  record  types  and 
dynamic  and  variant  record  types. 


Simple  Records 


A  record  that  has  no  discriminants,  no  dynamically  constrained 
composite  components,  and  no  unconstrained  components  is  a  simple 
record.  The  compiler  arranges  a  simple  record  so  that  each 
component  has  its  own  default  size  and  alignment,  relative  to  the 
base  of  the  record. 

The  algorithm  for  calculating  the  size  and  alignment  of  a  record 
follows: 

1.  For  each  component,  align  at  the  default  alignment  for  the 
component  type  and  allocate  space  for  the  component's  size. 

2.  Set  component  locations  as  follows: 

a)  Sort  components  by  alignment,  largest  first,  and  then  by 
order  of  declaration. 

b)  Assign  each  component  the  location  that  (1)  is  closest 
to  tne  base  of  the  record,  (2)  is  not  yet  assigned  to 
another  component,  and  (3)  meets  the  default  size  and 
alignment  requirements  of  the  component  type. 

3.  Set  the  alignment  of  the  record  to  the  largest  alignment  of 
its  components.  That  alignment  is  the  most  restrictive  and 
can  only  be  8  or  16  bits. 

4.  Set  the  size  of  the  record  to  the  sum  of  the  offset  of  the 
component  that  has  the  largest  offset  ('POSITION  attribute) 
and  the  size  of  that  component  rounded  up  to  the  next 
multiple  of  the  record  type's  alignment. 
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A  complex  record  has  at  least  one  of  the  following: 

•  Discriminants  (one  or  more) 

•  Dynamically  constrained  composite  components 

•  Unconstrained  components 

For  example,  consider  these  declarations: 

N  :  INTEGER  :-  F(10);  —  F  is  a  function, 
type  DYNAM I C_ARRA  Y  is  array  (1..N)  of  INTEGER; 
type  R(  D  :  NATURAL  )  is 
record 

A  :  NATURAL  :■  0; 

B  :  STRING(1. .D) ; 

Cl  :  DYNAM I C_ ARRAY; 

C2  :  DYNAMICARRAY; 
end  record; 

In  the  example,  R  is  a  complex  record  because  it  has  a 
discriminant  and  also  because  the  values  of  B ' LAST ,  Cl' LAST,  and 
C2 ' LAST  are  determined  at  run  time. 


Layout  of  Record  Components.  The  compiler  lays  the  record  compo¬ 
nents  out  in  the  following  order : 

1.  The  discriminants,  if  any 

2.  The  variant  index  field,  if  the  record  type  has  variants,  as 
if  the  variant  index  were  another  discriminant 

3.  Everything  the  compiler  knows  the  size  of  declared  in  the 
invariant  part 

4.  For  each  variant,  everything  the  compiler  knows  the  size  of 
declared  in  the  variant  part 

5.  Everything  the  compiler  does  not  know  the  size  of  declared  in 
the  invariant  part 

6.  For  each  variant,  everything  the  compiler  does  not  know  the 
size  of  declared  in  the  variant  part 
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The  compiler  always  determines  the  ordering  of  all  components  at 
compile  time.  It  cannot  determine  the  position  values  for  any 
component  the  compiler  does  not  know  the  size  of  at  compile  time 
or  for  any  component  constrained  by  a  discriminant,  except  for 
the  first  such  component. 


Components  With  Unknown  Sizes  or  Discriminant  Constraints.  The 
compiler  always  stores  components  it  does  not  know  the  size 
of  and  components  constrained  by  discriminants  at  the  end  of  a 
record.  If  the  record  has  more  than  one  of  these  components  per 
variant,  each  of  the  components  except  the  last  one  causes  the 
compiler  to  create  an  extra  component  and  assign  it  a  location 
within  the  record.  This  extra  component  holds  the  byte-relative 
offset  of  the  corresponding  component. 

The  extra  component  is  a  16-bit  field  aligned  on  a  16-bit 
boundary.  The  field  is  located  in  the  static  invariant  part  for 
a  corresponding  component  in  the  dynamic  invariant  part  or  in  the 
static  variant  part  for  a  corresponding  component  in  the  dynamic 
variant  part. 

If  a  record  subtype  is  constrained  and  has  no  dynamic  part,  the 
compiler  allocates  space  only  for  the  active  variant  parts.  If 
a  constrained  record  subtype  has  a  dynamic  part,  the  compiler 
allocates  space  for  all  variants  in  the  static  part  to  insure 
that  the  dynamic  part  of  all  subtypes  start  at  the  same  offset. 


Multidimensional  Subtypes.  When  a  record  component  is  a  multidi- 
mensional  subtype  in  which  more  than  one  bound  depends  on  a 
discriminant,  the  size  the  compiler  allocates  for  the  component 
can  be  the  minimum  space  the  component  needs  or  larger.  For 
example,  the  following  declaration  can  cause  the  compiler  to 
allocate  more  than  the  minimum  space  for  a  component: 

subtype  INT  is  INTEGER  range  1  ..  20; 
type  ARR  is  array  (INT  range  <>,  INT  range  <>)  of  INT; 
type  R  (D  :  INT  :■  5)  is 
record 

A  :  ARR  (1  . .  D,  D  . .  20) ; 
end  record; 

When  D  is  10,  the  number  of  components  in  A  is  110,  the  maximum 
size  that  A  can  be.  However,  the  compiler  plugs  in  the  upper-and 
lower  bounds  for  the  discriminant  type  in  the  appropriate  parts 
of  the  subtype  range  for  A  and  calculates  the  number  of. elements 
in  A  to  be  400. 
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Descriptor  Components.  For  each  component  in  the  record  that  has 
a  constraint  which  depends  on  a  discriminant  of  the  record,  the 
compiler  also  generates  an  additional  descriptor  component.  The 
size  of  the  descriptor  component  varies  with  the  type  of  the 
component,  as  described  under  "Run-Time  Descriptors,"  later  in 
this  appendix.  However,  the  alignment  is  always  16  bits. 


NOTE 

The  compiler  does  not  round  up  the  size  of  a  descriptor 
component  to  a  multiple  of  two  bytes. 


The  compiler,  at  compile  time,  sizes  the  components  it  generates 
and  allocates  space  for  them  in  the  appropriate  static  areas. 

If  a  descriptor's  corresponding  component  is  in  the  dynamic 
invariant  part,  then  the  descriptor  component  goes  in  the  static 
invariant  part.  If  a  descriptor's  corresponding  component  is  in 
the  dynamic  variant  part,  then  the  descriptor  component  goes  in 
the  static  variant  part. 

For  a  variant  record,  the  compiler  also  generates  a  16-bit 
variant  index  field.  The  compiler  uses  the  index  field  to 
simplify  component  selection  checks.  The  alignment  cf  the  index 
field  is  16  bits. 


Representation  of  Complex  Records.  The  algorithm  for  determining 
the  representation  of  complex  records  follows: 

1.  Divide  the  components,  including  compiler-generated 
components,  into  three  groups: 

•  Discriminants 

•  Invariants 

•  Variant  part 

2.  Apply  the  algorithm  for  laying  out  simple  record  components 
to  the  set  of  discriminants. 

3.  If  the  record  type  has  any  variants,  generate  a  variant  index 
field.  Place  the  index  field  at  the  location  closest  to  the 
base  of  the  record  that  (1)  is  not  assigned  to  a  discriminant 
and  (2)  has  a  size  of  2  bytes  and  an  alignment  of  2  bytes. 
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4.  Apply  a  slightly  modified  version  of  the  algorithm  for 
laying  out  simple  records  to  the  set  of  everything  the 
compiler  knows  the  size  of  in  the  invariant  part.  The 
only  modification  is  that,  for  each  component,  the  compiler 
allocates  the  unoccupied  location  closest  to  the  last  loca¬ 
tion  occupied  by  a  discriminant,  or  by  the  variant  index 
field  if  present,  instead  of  the  unoccupied  location  closest 
to  the  base  of  the  record. 

5.  For  each  variant  case,  lay  out  everything  the  compiler 
knows  the  size  of,  using  a  slightly  modified  version  of 
the  algorithm  for  laying  out  simple  records.  The  only 
modification  is  that,  for  each  component,  the  compiler 
allocates  the  location  closest  to  the  last  location  occupied 
by  a  component  in  the  static  invariant  part,  instead  of 

the  unoccupied  location  closest  to  the  base  of  the  record. 

The  compiler  computes  each  variant  case  independently  of 
any  of  the  others,  so  components  in  one  ordinarily  overlay 
components  in  another. 

6.  Lay  out  the  subvariants,  if  any,  within  each  variant  in  the 
same  manner  as  the  variants. 

7.  Finally,  at  run  time,  lay  out  components  the  compiler  does 
not  know  the  size  of  and  components  that  are  constrained  by 
discriminants.  The  size  of  an  unconstrained  component  is  the 
maximum  possible  size  for  that  component. 

The  algorithm  for  laying  out  the  components  in  the  final  step 
follows: 

a)  For  each  invariant  component,  apply  a  slightly  modified 
version  of  the  algorithm  for  laying  out  simple  records. 
The  only  modification  is  that  each  component  is  allocated 
the  location  closest  to  the  last  location  occupied  by 

a  component  ir.  all  of  the  static  variant  parts,  instead 
of  the  unoccupied  location  closest  to  the  base  of  the 
record. 

b)  For  each  variant  case,  lay  out  the  components  the 
compiler  does  not  know  the  size  of  and  the  components 
that  are  constrained  by  discriminants,  using  a  slightly 
modified  version  of  the  algorithm  for  laying  out  simple 
records.  The  only  modification  is  that  each  component 
is  allocated  the  location  closest  to  the  last  location 
occupied  by  a  component  in  the  dynamic  variant  part, 
instead  of  the  unoccupied  location  closest  to  the  base  of 
the  record.  Each  variant  case  is  computed  independently 
of  any  of  the  others,  so  components  in  one  ordinarily 
overlay  components  in  another. 
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The  compiler  can  always  determine  the  ordering  of  all 
components  at  compile  time,  but  the  position  values  for 
components  the  compiler  does  not  know  the  size  of  and 
components  constrained  by  discriminants  must  be  computed  at 
run  time. 

For  the  record  R,  we  might  arrive  at  the  following  layout  for  a 
declaration  of  R(D  *>  5)  and  N'  :■  5: 


Component  Position 

D  0 

A  2 

B's  Indirect  Pointer  4 

B's  Descriptor  6 

C2 ' s  Indirect  Pointer  14 

Cl  16 

C2  26 

B  36 


There  is  no  indirect  pointer  for  the  dynamic  component  Cl  because 
it  is  the  first  dynamic  component  in  the  record.  The  compiler 
determines  this  component's  offset  within  the  record  at  compile 
time. 

Figure  F-l  illustrates  the  layout  of  the  record  R. 
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Access  Types 


The  size  of  an  access  type  depends  on  whether  the  accessed  type  I 

is  constrained  and  on  whether  the  accessed  type  is  completed  in  I 

the  same  compilation  with  its  incomplete  type  specification.  The  I 
compiler  allocates  64  bits  for  an  access  type  to  .an  unconstrained 
record  or  array  subtype.  The  compiler  also  allocates  64  bits  for  I 
an  access  type  to  a  type  not  completed  in  the  same  compilation,  I 
if  the  corresponding  full  type  declaration  for  the  accessed 
type  does  not  occur  before  a  forcing  occurrence  of  the  access 
type.  (Section  13.1  of  the  ANSI  Reference  Manual  for  the  Ada 
Programming  Language  defines  forcing  occurrence.)  For  any  other 
access  type,  the  compiler  allocates  32  bits. 

Subtypes  and  derived  types  of  access  types  always  have  the  same 
sizes  as  their  base  or  parent  types. 


Task  Types 


The  size  of  a  task  type  is  32  bits.  The  32  bits  contain  a  task 
identifier. 


Component  Clauses 


A  record  representation  clause  can  give  one  or  more  component 
clauses  for  a  record.  The  representation  clause  is  legal  if  the 
compiler  can  assign  all  the  specified  locations  and  sizes  without 
incorrectly  overlapping  any  fields. 

For  any  field  mentioned  with  a  component  clause,  the  compiler 
assigns  precisely  the  specified  location  and  size.  After  it 
locates  all  such  fields,  the  compiler  applies  the  algorithm 
described  in  the  preceding  ter.*-  to  locate  the  remaining  fields. 

In  doing  so,  it  avoids  incorrectly  overlapping  those  fields 
that  it  explicitly  located.  In  any  case,  the  alignment  of  a 
record  type  that  has  a  component  clause  is  equal  to  the  largest 
component  alignment. 

For  any  component,  the  size,  as  implied  by  the  range,  must  be 
the  same  as  the  size  of  the  component  type.  The  alignment 
for  any  component  relative  to  the  base  of  the  record  must 
be  a  multiple  of  the  alignment  of  the  component's  type.  A 
record  representation  clause  cannot  specify  the  insertion  of  a 
component  from  a  component  list  or  the  discriminant  part  of  a 
type  declaration  into  another  component  list  or  the  discriminant 
part  of  the  same  type  declaration.  (For  an  explanation  of 
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component  lists,  see  sections  3.7  and  3.7.3  of  the  ANSI  Reference 
Manual  for  the  Ada  Programming  Language .) 

For  example,  the  following  record  representation  clause  is 
illegal  because  it  tries  to  place  a  variant  component  in  the  list 
of  invariant  components. 

type  R  (D  :  INTEGER)  is 
record; 

A,  B  :  INTEGER; 

case  D  is 
when  0  ■> 

C  ;  INTEGER; 
when  others  *> 
null ; 
end  case; 
end  record; 

for  R  use 
record 

—  D  is  at  0  range  0..15. 

—  Variant  index  is  at  4  range  0..15. 

A  at  6  range  0 . . 15; 

B  at  10  range  0. . 15; 

C  at  8  range  0 . . 15; 

end  record; 

I  To  make  this  representation  clause  legal,  the  position  of 
i  component  C  should  follow  the  position  of  component  B. 
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In  record  representation  clauses,  you  must  leave  space  in  the 
component  list  for  the  following: 

•  Variant  index  field,  which  the  compiler  puts  in  the  discrimi¬ 
nant  part 

•  Descriptors  for  dependent  subtypes,  described  in  "Descriptor 
Components"  under  "Complex  Records,"  earlier  in  this  appendix 

•  Indirect  pointers  to  components,  described  in  "Components 
With  Unknown  Sizes  or  Discriminant  Restraints"  under  "Complex 
Records,"  earlier  in  this  appendix 

A  representation  clause  can  leave  space  fcr  the  variant  index 
anywhere  in  the  discriminant  part,  before  the  first  component, 

A.  The  compiler  considers  the  variant  index  to  be  part  of  the 
component  list  of  discriminants.  For  example,  the  following 
representation  clause  is  illegal: 

type  R  (D  :  INTEGER)  is 
record 

I  j  INTEGER; 
case  D  is 

when  1  *>  J  :  INTEGER; 
when  others  =>  null; 
end  case; 
end  record; 

for  R  use 
record 

D  at  0  range  0 . . 15; 

I  at  2  range  0 . . 15 ; 

end  record 

The  compiler  cannot  honor  the  representation  clause  for  component 
I  because  it  already  placed  the  variant  index  at  2  range  0..15. 
The  same  applies  to  components  the  compiler  does  not  know  the 
size  of  and  components  constrained  by  discriminants. 
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Alignment  Clauses 


An  alignment  clause  in  a  record  representation  clause  affects 
only  the  alignment  of  the  record.  It  does  not  affect  the  layout 
of  the  components  of  the  record. 

The  following  examples  illustrate  the  use  of  an  alignment  clause 

Sample  record  type: 

type  S  is  range  0..1000; 

type  Q  is  range  0..20; 

type  T  is 

record 

A  :  CHARACTER; 

B  :  LONG_ I NTEGER ;  --  32  bits 
C  :  S; 

D  :  Q; 
end  record; 

Default  representation: 
for  T  use 

record  at  mod  2  —  SYSTEM. STORAGE_UN IT  *  8  bits 
B  at  0  range  0 , .  31 ; 

C  at  4  range  0.  .15; 

A  at  6  range  0. .7; 

D  at  7  range  0 . . 7; 
end  record; 

for  T'SIZE  use  64;  --  bits 
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Restrictions  on  Representation  Clauses 


In  addition  to  the  rules  for  representation  clauses  and  represen¬ 
tation  pragmas  in  the  ANSI  Reference  Manual  for  the  Ada 
Programming  Language ,  Tandem  Ada  has  restrictions  on  the 
following : 

•  Size  specifications  in  length  clauses 

•  Record  representation  clauses 

•  Address  clauses 

•  Enumeration  representation  clauses 

•  Specification  of  'SMALL  for  fixed-point  types 

•  Specification  of  ' STORAGE_S I ZE 


Size  Specifications  in  Length  Clauses 


For  records  and  arrays,  the  value  of  the  static  expression  in 
a  length  clause  for  T'SIZE  must  be  a  multiple  of  8  and  of  the 
alignment.  Also,  the  value  must  be  at  least  as  large  as  the 
default  size  the  compiler  calculates  for  T. 

Table  F-4  shows  the  possible  values  of  N  for  different  data  types 
in  the  clause  for  T'SIZE  use  N.  For  scalar  types,  just  a  few 
values  are  valid.  You  cannot  use  the  length  clause  for  access 
types. 
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Table  F-4.  Size  Specifications  for  Different  Types 


Type 

Possible  Values 

of  T’SIZE 

Integer 

8,  16,  32,  and 

64 

Enumeration 

8  and  16 

Fixed  point 

64 

Floating  point 

32  and  64 

Task 

32 

Composite 

Multiples  of  8 

and  of  the  alignment 

Access 

Not  Supported 

If  a  representation  clause  increases  the  size  of  a  type,  then 
the  compiler  creates  some  filler  space.  For  scalar  types,  which 
the  compiler  always  stores  right  justified  within  a  container, 
the  filler  space  is  sign  extended.  For  composite  types,  which 
the  compiler  always  stores  left  justified  within  a  container,  the 
filler  space  is  zero  filled. 

A  subtype  of  a  type  typically  has  the  same  size  as  the  type; 
however,  a  constrained  record  subtype  can  be  smaller  than  the 
record  type.  If  you  specify  a  length  clause  for  the  record  type, 
the  compiler  uses  the  length  in  the  clause  to  allocate  space 
for  the  type.  But  when  allocat’^g  space  for  an  object  of  a 
constrained  subtype,  the  compiler  ignores  the  length  clause  for 
the  type  and  chooses  a  size  for  the  subtype. 
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Record  Representation  Clauses 


The  following  restrictions  apply  to  component  clauses  (at  N  range 
L  .  .  R ) : 

•  The  compiler  must  be  able  to  determine  the  size  of  the 
component  subtype  at  compile  time,  as  explained  under  "Sizes 
the  Compiler  Knows  at  Compile  Time,"  earlier  in  this  appendix. 

•  The  size  of  the  range  you  specify  (R-L+l)  must  equal  the  size 
of  the  component  type. 

•  The  value  for  L  must  be  a  multiple  of  8.  The  component  must 
begin  on  a  byte  boundary. 

•  All  values  supplied  for  a  record  component  offset  must  be 
nonnegative  (N  *  8  +  L  >■  0). 

•  Components  from  a  variant  part  must  follow  components  from  the 
fixed  part  in  the  record  layout. 

The  compiler's  layout  algorithm  implies  some  additional  restric¬ 
tions.  For  a  description  of  the  algorithm,  see  "Complex  Records" 
under  "Record  Types,"  earlier  in  this  appendix. 

The  following  restrictions  apply  to  alignment  clauses  (at  mod  N); 

•  The  value  of  N  must  be  at  least  as  large  as  the  default 
alignment  the  compiler  chose  for  the  record. 

•  The  value  of  N  must  be  either  1  or  2  bytes. 

The  Tandem  Ada  compiler  does  not  support  record  representation 
clauses  for  records  that  contain  generic  formals. 


Address  Clauses 


The  Tandem  Ada  compiler  does  not  support  address  clauses. 


Enumeration  Representation  Clauses 


The  Tandem  Ada  compiler  does  not  support  enumeration  representa¬ 
tion  clauses. 
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Specification  of  'SMALL  for  Fixed-Point  Types 


I  The  value  of  the  static  expression  in  a  length  clause  for  'SMALL 
I  must  be  a  power  of  2  in  the  following  range: 

2  **  (-256)  to  2  **  255 

I  The  value  specified  for  'SMALL  must  be  in  the  range  precisely 
represented  by  the  positive  range  of  the  predefined  types  FLOAT 
and  LONG_FLOAT. 

The  ANSI  Reference  Manual  for  the  Ada  Programming  Language  also 
impiles  that  the  value  must  satisfy  the  following  relation: 

max  (ceiling  (log2  (abs  (LB)  /  small)), 

ceiling  (log2  (abs  (UB)  /  small)))  <«  SYSTEM. MAX_MANT I SSA 

In  other  words,  the  number  of  binary  digits  in  the  mantissa  of 
the  model  numbers  for  fixed-point  type  must  be  less  than  or  equal 
to  the  maximum  number  of  binary  digits,  SYSTEM. MAX_MANT I SSA, 
which  is  31. 


Specification  of  ' STORAGE_S I 2E 


For  tasks,  the  value  you  specify  for  ' STORAGE_S I 2E ,  must  be 
greater  than  0  but  less  than  2  **  27  bytes.  The  default  is 
2  **  18  bytes.  For  a  description  of  how  tasks  use  memory,  see 
"Memory  Usage  on  Nonstop  Systems,"  later  in  this  appendix. 

Tandem  Ada  does  not  support  ' STORAGE_S I ZE  for  access  types. 
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Representation  Attributes 


The  Tandem  Ada  compiler  supports  all  representation  attributes. 
However,  the  following  attributes  might  not  have  meaningful 
values : 

•  ' ADDRESS 

'ADDRESS  returns  the  32-bit  extended  address  of  an  object. 

(For  a  task  object,  it  returns  the  address  of  the  variable 
that  contains  the  task  identifier.) 

Meaningful  addresses  exist  for  some,  but  not  all,  objects. 

You  can  use  the  'ADDRESS  attribute  to  determine  whether  an 
object  has  a  meaningful  address. 

For  example,  to  determine  whether  an  object  of  type  T  has 
a  meaningful  address,  first  declare  an  access  type — call  it 
A — whose  designated  subtype  is  T,  and  instantiate 
UNCHECKED_CONVERS I OH  for  types  SYSTEM . ADDRESS  and  A.  Then,  if 
an  object  of  type  T  does  not  have  a  meaningful  address,  the 
result  of  using  the  'ADDRESS  attribute  followed  by  unchecked 
conversion  to  type  A  is  the  value  null.  If  objects  do  have 
meaningful  addresses,  the  result  of  the  conversion  is  a  valid, 
non-null  access  value,  which  you  can  use  to  gain  access  to  the 
corresponding  object  of  type  T. 


NOTE 

Unchecked  conversion  between  SYSTEM. ADDRESS  and  an  ac¬ 
cess  type  is  possible  only  for  access  types  represented 
in  32  bits.  If  T  is  an  unconstrained  type  or  is  not 
completed  in  the  same  compilation,  an  access  value  to 
type  T  might  require  64  bits,  as  explained  earlier  in 
this  appendix  under  "Access  Types."  In  such  cases, 
use  the  corresponding  full  type  declaration  of  T,  or  a 
constrained  subtype  of  T,  for  the  designated  subtype  of 
A. 


•  'STORAGE_SIZE 

For  access  types  or  subtypes,  this  attribute  does  not  return  a 
meaningful  value. 

For  tasks,  if  the  program  gives  a  storage-size  representation 
clause,  then  ' STORAGE_S I ZE  returns  that  value.  Otherwise, 

' STORAGE_S I ZE  returns  the  default  task  storage  size,  which  is 
2  **  18. 
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This  section  describes  record  and  array  subtype  descriptors. 

When  the  calling  program  passes  an  actual  parameter  corresponding 
to  an  unconstrained  formal  parameter,  it  also  passes  a  pointer 
to  a  subtype  descriptor.  The  program  pushes  the  pointer  to  the 
descriptor  onto  the  stack  immediately  after  the  pointer  to  the 
data. 

The  compiler  also  uses  a  run-time  descriptor  when  record  compo¬ 
nents  depend  on  discriminants. 


Record  Subtype  Descriptors 


A  record  subtype  descriptor  describes  a  record  subtype.  Each 
record  descriptor  is  at  least  four  bytes.  All  record  descriptors 
have  a  size  field  and  a  field  that  tells  whether  the  subtype  is 
constrained.  The  second  field  occupies  two  bytes. 

If  a  record  subtype  is  constrained,  its  descriptor  has  additional 
fields  containing  a  copy  of  the  discriminant  values  of  the 
subtype.  The  compiler  lays  out  the  descriminant  values  in  the 
record  descriptor  in  the  same  way  as  it  lays  them  out  in  the 
actual  record,  beginning  where  the  discriminant  part  begins  in 
the  record  layout.  For  example,  if  a  discriminant  is  at  offset  X 
in  the  actual  record,  and  the  smallest  offset  of  any  discriminant 
in  the  actual  record  is  Y,  then  that  same  discriminant  is  at 
offset  X-Y+4  in  the  record  descriptor. 

--  The  following  declaration  describes  a  descriptor  for  a 
—  record  subtype: 

type  RECORD_DESCRI PTOR  is 
record 

SIZE  :  INTEGER;  --  at  0  range  0  . .  15 

IS  CONSTRAINED  :  INTEGER;  —  at  2  range  0  . .  15 

RECORD_D I SCR I M I NANTS  :  D I SCRIM  RECORD; 

— If~the  record  is  constrained  and  has 
--discriminants,  then  this  field  is  a  copy 
--of  the  discriminant  constraints  of  the 
— record  subtype. 

•nd  record; 


NOTE 

The  compiler  does  not  round  up  the  size  of  a  descriptor 
component  to  a  multiple  of  two  bytes. 
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An  array  subtype  descriptor  describes  an  array  subtype.  Each 
descriptor  specifies  an  array  of  records  with  two  numeric  fields 
and  an  array  of  array  strides.  Each  of  these  arrays  has  from 
1  to  7  elements,  depending  upon  the  number  of  dimensions  of  the 
array  being  described.  The  compiler  knows  this  number  at  compile 
time.  The  last  field  in  the  descriptor  is  the  array  size. 

Examples  of  array  subtype  descriptors  follow: 

MAX_INDICES  :  constant  INTEGER  :=  7; 

subtype  INDEX_COUNT  is  INTEGER  range  1  ..  MAX_INDICES; 
subtype  STRIDE  is  INTEGER; 

type  STR I DE_ ARRAY  is  array  (INDEX_COUNT  range  <>) 

of  STRIDE; 

type  AIT  is 
record 

LOWER_BOUND  :  INTEGER; 

UPPER_30UND  :  INTEGER; 
end  record; 

type  AIT_ARRAY  is  array  (INDEX_COUNT  range  <>)  of  AIT; 

type  LONG_AIT  is 
record 

LOWER_BOUND  :  LONG_ I NTEGER ; 

UPPER_BOUND  :  LONG_ I NTEGER; 
end  record; 

type  LONG_AIT  ARRAY  is  array  (INDEX_COUNT  range  <>) 

of  LONG_AIT; 

type  LONG_LONG_A I T  is 
record 

LOWER_BOUND  :  LONG_LONG_ I NTEGER; 

UP?ER_BOUND  :  LONG_LONG_ I  NTEGER ; 
end  record; 

type  LONG_LONC  AIT  ARRAY  is  array  (INDEX  COUNT  range  <>) 

of  LONG  LONG'AIT; 
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— The  following  types  describe  arrays  that  have  index  - 

less  than  or  equal  to  16  bits. 

type  ARRAY_DESCR I PTOR_l  is  --for  a  1-dimensional  array 
record 

AIT  :  A I T_ ARRAY  (1  ..  1); 

STRIDE  :  STRI DE_ARRAY  (1  ..  1); 

SIZE  :  INTEGER; 
end  record; 

type  ARRAY_DESCRIPT0R_2  is  --for  a  2-dimensional  array 
record 

AIT  ;  AIT_ARRAY  (1  ..  2); 

STRIDE  :  STRI DE_ARRAY  (1  ..  2); 

SIZE  ;  INTEGER; 

end  record; 

type  ARRAY_D£SCRIPT0R_3  is  — for  a  3-dimensional  array 
record 

AIT  :  AIT_ARRAY  (1  ..  3); 

STRIDE  :  STRI DE_ARRAY  (1  ..  3); 

SIZE  :  INTEGER; 

end  record; 

type  ARRAY_DESCR I PTOR_4  is  — for  a  4-dimensional  array 
record 

AIT  :  AIT_ARRAY  (1  ..  4); 

STRIDE  J  STR I DE_ARRA Y  (1  ..  4); 

SIZE  ;  INTEGER; 
end  record; 

type  ARRAY_DESCR I PTOR_5  is  — for  a  5-dimensional  array 
record 

AIT  :  AIT_ARRAY  (1  ..  5); 

STRIDE  ;  STRIDE  ARRAY  (1  ..  5); 

SIZE  :  INTEGER; 
end  record; 

type  ARRAY_DESCRIPT0R_6  is  --for  a  6-dimensional  array 
record 

AIT  ;  AIT  ARRAY  (1  ..  6); 

STRIDE  ;  STRTDE_ARRAY  (1  ..  6); 

SIZE  ;  INTEGER; 

end  record; 

type  ARRAY_DESCRIPTOR  7  is  --for  a  7-dimensional  array 
record 

AIT  ;  AIT  ARRAY  (1  . .  7) ; 

STRIDE  ;  STRIDE  ARRAY  (1  ..  7); 

SIZE  :  INTEGER; 

end  record; 


-subtypes 
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--The  following  types  describe  arrays  that  have  at  least 
--one  index  subtype  greater  than  16  bits  and  no  index 
--subtype  greater  than  32  bits. 

type  LONG_ARRAY_DESCRI PTOR_l  is  --for  a  1-dimensional  array 
record 

AIT  :  LONG_AIT  ARRAY  (1  ..  1); 

STRIDE  :  STR I DE_ARRAY  (1  ..  1); 

SIZE  :  INTEGER; 

end  record; 

type  LONG_ARRAY_DESCRI PT0R_2  is  --for  a  2-dimensional  array 
record 

AIT  :  LONG_AIT  ARRAY  (1  ..  2); 

STRIDE  :  STRIDE  ARRAY  (1  ..  2); 

SIZE  :  INTEGER; 

end  record; 

type  LONG_ARRAY_DESCRIPTOR_3  is  --for  a  3-dimensional  array 
record 

AIT  ;  LONG_AIT  ARRAY  (1  ..  3); 

STRIDE  :  STRIDE  ARRAY  (1  ..  3); 

SIZE  :  INTEGER; 

end  record; 

type  LONG_ARRAY_DESCRIPTOR_4  is  —for  a  4-dimensional  array 
record 

AIT  :  LONG_AIT  ARRAY  (1  ..  4); 

STRIDE  :  STR I DE_ARRAY  (1  ..  4); 

SIZE  ;  INTEGER; 

end  record; 


type  LONG_ARRAY_DESCR I PT0R_5  is  — for  a  5-dimensional  array 
record 

AIT  ;  LONG_A I T  ARRAY  (1  ..  5); 

STRIDE  ;  STRIDE_ARRAY  (1  ..  5); 

SIZE  ;  INTEGER; 
end  record; 

type  LONG_ARRAY_DESCRIPTOR_€  is  — for  a  6-dimensional  array 
record  “ 

AIT  j  LONG  AIT  ARRAY  (1  ..  6); 

STRIDE  ;  STRIDE  ARRAY  (1  ..  6); 

SIZE  ;  INTEGER; 
end  record; 

type  L0NG_ARRAY_DESCRIPT0R_7  is  — for  a  7-dimensional  array 
’  record 

AIT  ;  LONG_AIT_ARRAY  (1  ..  7); 

STRIDE  ;  STRIDE  ARRAY  (1  ..  7); 

S  SIZE  :  INTEGER; 

end  record; 
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— The  following  types  describe  arrays  that  have  at  least  one 

--index  subtype  greater  than  32  bits  and  no  index  subtype 

--greater  than  64  bits. 

type  LONG_LONG_ARRAY_DESCRI PT0R_1  is  --for  a  1-dimensional  array 

record  ~ 

AIT  :  LONG_LONG  AIT  ARRAY  (1  ..  1); 

STRIDE  :  STRI DE_ARRAY  Tl  ..  1); 

SIZE  :  INTEGER; 
end  record; 

type  L0NG_L0NG_ARRAY_DESCRIPT0R_2  is  --for  a  2-dimensional  array 
record 

AIT  :  LONG_LONG_A I T  ARRAY  (1  ..  2); 

STRIDE  :  STRI DE_ARRAY  Tl  ..  2); 

SIZE  :  INTEGER; 

end  record; 

type  LONG_LONG_ARRAY_DESCRIPTOR_3  is  --for  a  3-dimensional  array 
record 

AIT  :  LONG_LONG_A I T  ARRAY  (1  ..  3); 

STRIDE  :  STRI DE_ ARRAY  Tl  ..  3); 

SIZE  :  INTEGER; 

end  record; 

type  LONG_LONG_ARRAY_DESCRIPTOR_4  is  — for  a  4-dimensional  array 
record 

AIT  :  LONG_LONG_A I T  ARRAY  (1  ..  4); 

STRIDE  ;  STRI DE_ARRAY  Tl  ..  4); 

SIZE  :  INTEGER; 

end  record; 

type  LONG_LONG_ARRAY_DESCRIPTOR_5  is  — for  a  5-dimensional  array 
record 

AIT  :  LONG_LONG_A I T  ARRAY  (1  ..  5); 

STRIDE  :  STRIDE_ARRAY  Tl  ..  5); 

SIZE  :  INTEGER; 

end  record; 

type  LONG_LONG_ARRAY_DESCRIPTOR  6  is  — for  a  6-dimensional  array 
record  ~ 

AIT  :  LONG  LONG  AIT  ARRAY  (1  ..  6); 

STRIDE  :  STRIDE_ARRAY  Tl  ..  6); 

SIZE  :  INTEGER; 

end  record; 

type  LONG_LONG_ARRAY_DESCRIPTOR  7  ~is  — for  a  7-dimensional  array 
record 

AIT  :  LONG  LONG  AIT  ARRAY  (1  ..  7); 

STRIDE  s  STRIDE  ARRAY  Tl  ..  7); 

SIZE  :  INTEGER; 

end  record; 


B-47 


V 


IMPLEMENTATION- DEPENDENT  CHARACTER! ST  I CS 
Unchecked  Type  Conversions 


UNCHECKED  PROGRAMMING 


This  subsection  explains  when  you  can  use  instances  of  the 
predefined  generic  subprograms  for  unchecked  programming  and  what 
they  do.  For  complete  descriptions  of  UNCHECKED  DEALLOCATION 
and  UNCHECKED_CONVERS I  ON ,  see  Section  13.10  of  tKe  ANSI  Reference 
Manual  for  the  Ada  Programming  Language. 


Unchecked  Storage  Deallocation 


The  generic  procedure  UNCHECKED_DEALLOCATION  resets  an  access 
value  to  null  but  does  not  reclaim  the  memory  space  used  by  the 
allocated  object. 

The  compiler  reclaims  any  space  it  allocates  for  temporary 
variables  it  creates  for  execution  of  a  subprogram.  However, 
the  compiler  does  not  automatically  do  garbage  collection  of  data 
that  a  program  creates. 


Unchecked  Type  Conversions 


The  generic  function  UNCHECKED_CONVEP.SION  has  the  following 
restrictions: 

•  The  source  and  target  types  must  have  the  same  size,  and  the 
compiler  must  be  able  to  determine  the  size  at  compile  time. 

For  information  about  sizes  the  compiler  can  determine  at 
compile  time,  see  "Sizes  the  Compiler  Knows  at  Compile  Time," 
earlier  in  this  appendix. 

•  The  source  and  target  types  must  not  be  unconstrained  records  I 

or  arrays.  I 
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I NPUT-OUTPUT  PACKAGES 


Tandem's  Ada  compiler  supports  SEQUENT  I AL_IO,  DIRECT_IO,  and 
TEXT  10.  I/O  routines  recognize  only  disk  files,  terminals,  and 
spoolers.  If  an  output  file  is  a  process  other  than  a  terminal, 
the  I/O  routines  trect  the  file  like  a  spooler. 

Calling  subprograms  in  LOW_LEVEL_IO  does  not  cause  any  I/O 
operations  to  be  performed? 


FORM  Parameter  of  CREATE  and  OPEN  Procedures 


The  FORM  parameter  of  the  CREATE  and  OPEN  procedures  in  the 
TEXT_IO,  DIRECT_IO ,  and  SEQUENTIAL_IO  packages  has  the  following 
syntax : 

form-string 

create-open-spec  {,  create-open-spec} 

create-open-spec  create-spec  I  open-spec  I  null 

--  Create-spac  is  only  for  the  CREATE 
—  procedure.  Open-spec  is  for  both  the 
—  CREATE  and  OPEN  procedures. 

create-spec 

DATA_BLOCKLEN  =  block-length  —  This  data-block  length 

—  is  for  structured  files. 

—  The  default  is  1024.  You 

—  can  specify  any  integer  in 

—  the  range  1..4096.  If  you 

—  do  not  specify  512,  1024, 

—  2048,  or  4096,  the  compiler 
--  rounds  the  block  length  up 
--  to  the  next  highest  of 

—  these  values. 

I  FILE_C0DE  »  code-number  —  The  code  number  is  the 

--  operating  system  file  code, 

—  any  integer  in  the  range 

—  0.. 65535.  When  a  program 

—  uses  TEXT  10  with  an  edit- 

—  format  file,  the  file  code 

—  is  always  101,  and  if  you 

—  try  to  specify  it,  the 

--  program  raises  USE_ERROR. 

--  For  TEXT  10  with  other  file 

—  types  an3  for  DIRECT_IO  and 
--  SEQUENTIAL^IO,  the  difault 

—  file  code  Is  0. 


B -4  9 


implementation-dependent  chap ac . .  :st:cs 

FORM  Parameter  of  CREATE  and  OPEN  ?rc:ed_res 


I  PRIMARY_EXTENT__S I ZE  «  extent-size  —  The  extent  size  is 

--  any  integer  in  the  range 
--  0. .65535.  The  default 
--  primary  extent  size  is  4. 

I  SECONDARY_£XTENT_S I ZE  =  extent-size  --  The  extent  size 

--  any  integer  in  the  range 
--  0.. 65535.  The  default 
--  secondary  extent  size  is  16. 

I  FI LE_TYPE  -  file-type 

I  RECORDLEN  *  record-length  --  The  record  length  is  any 

--  integer  in  the  range 
--  1..1320.  This  option 
--  specifies  the  maximum  record 

—  length,  which  applies  only 
--  when  a  program  creates  a 

—  relative  or  entry-sequenced  I 
--  file  through  TEXT_IO.  The 

—  default  record  length  is  I 

—  132  for  relative  files  and  I 

—  1320  for  entry-sequenced  I 

—  files.  I 

I  ODDUNSTR  —  This  option  works  like  the 

—  file-system  CREATE  proce- 

—  dure’s  ODDUNSTR  parameter. 

—  For  a  description  of  the 
—  ODDUNSTR  parameter,  see 

—  the  System  Procedure  Calls 
—  Reference  Manual. 

file-type  U  I  R  I  E  I  D  —  U  is  for  unstructured, 

—  R  for  relative,  E  for  entry 

—  sequenced,  and  D  for  edit 

—  format.  For  TEXT_IO,  the 

—  default  file  type  is  E. 

—  For  DIRECT_IO,  the  default 

—  type  is  R,  and  an  attempt 

—  to  specify  anything  else 

—  raises  USE_ERROR.  For 

—  SEQUENT I AL_IO,  the  default 

—  type  is  E,  and  an  attempt. 

—  to  specify  anything  else 
— _  raises  USE_ERROR. 

open-spec  SHAPvED  I  EXCLUSIVE  I  PROTECTED  — For  opening 

—  any  type  of  file  with  mode 

—  in,  the  default  is  SHARED. 

—  For  creating  a  SEQUENT I AL_ I 0 

—  or  TEXT_IO  file,  the  default 

—  is  EXCLUSIVE.  For  creating 

—  a  DIRECT_IO  file  or  opening 
--  a  DIRECT_IO  file  with  mode 

—  in  out  or  out,  the  default 

—  is  EXCLUSIVE,  and  no  other 

—  open-spec  is  allowed. 
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null  : : * 


A  null  create-open-spec  is 
zero  or  more  blanks. 


Order  of  Options 


In  the  FORM  parameter,  you  can  specify  the  options  in  any  order. 
Also,  you  can  specify  each  option  only  once. 


IN  and  OUT  Files  for  an  Ada  Process 


The  TEXT_IO  package  opens  the  IN  file  and  the  OUT  file  for  the 
Ada  process  using  the  file  names  supplied  by  the 
COMMAND_INTERPRETER_INTERFACE  package  for  the  default  IN  and  OUT 
files.  You  can  specify  the  default  IN  file  and  OUT  file  for 
the  process  in  the  RUN  command.  If  you  do  not,  the  command 
interpreter  passes  the  names  of  its  current  defualt  IN  and  OUT 
files  in  the  startup  message  for  the  new  process. 

If  the  file  named  as  the  OUT  file  does  not  exist,  TEXT_IO  creates 
a  new  file,  using  all  the  default  values  of  the  CREATE  procedure 
(that  is,  it  creates  an  edit-format  file).  If  the  file  named 
as  the  OUT  file  already  exists,  TEXT  10  deletes  the  file  and 
recreates  it  with  the  same  characteristics  it  had. 


Startup,  Assign,  and  Pararo  Messages 


The  TEXT^IO  package  names  the  COMMAND^  INTERPRETER  INTERFACE 
package  In  a  with  clause.  As  a  result,  any  program  that  uses 
the  TEXT_I0  package  automatically  reads  the  startup,  assign,  and 
param  messages  on  SRECEIVE.  To  use  any  of  the  information  in  the 
messages,  the  program  must  also  name  the 
COMMAND_INTERPRETER_PACKAGE  in  a  with  clause. 
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File  Open  Mode 


An  open-spec  in  the  FORM  parameter  specifies  the  operating  system 
open  mode  for  the  file.  The  value  of  the  open-spec  depends  on 
the  kind  of  file  and,  for  disk  files,  the  purpose  for  which  the 
program  opens  the  file.  You  can  specify  only  EXCLUSIVE  for  the 
following : 

•  Creation  of  a  disk  file 

•  Opening  a  DIRECT_IO  file  with  mode  in  out  or  mode  out 

The  value  is  always  SHARED  for  terminals  and  spoolers. 

Resetting  any  kind  of  file  to  mode  in  does  not  affect  the  open- 
spec  previously  specified  for  the  file.  However,  if  an  Ada 
program  resets  a  DIRECT_IO  file  to  mode  in  out  or  mode  out,  the 
run-time  routines  close  and  reopen  the  file  with  an  open-spec 
of  EXCLUSIVE,  even  if  it  was  not  EXCLUSIVE  before.  If  an  Ada 
program  opens  or  resets  a  SEQUENT  I  AL__  10  or  TEXT_IO  file  with  mode 
in  out,  the  run-time  routines  recreate  the  file,  and  the  default 
open-spec  is  EXCLUSIVE;  you  can  override  the  open-spec  only  if 
the  program  is  opening  the  file. 


Record  Length  Specification 


You  can  specify  the  RECORDLEN  option  in  a  create-spec  only  when 
the  program  uses  TEXT  10  with  a  relative  or  entry-sequenced  file. 
For  either  type  of  file,  an  attempt  to  specify  a  record  length 
larger  than  1320  raises  USE_ERR0R.  If  you  do  not  specify  the 
record  length,  TEXT  10  uses  132  for  a  relative  file  or  1320  for 
an  entry-sequenced  Tile. 

An  attempt  to  specify  RECORDLEN  raises  USE_ERR0R  when  the  program  I 
uses  DIRECT_I0,  SEQUENT I AL_I0,  or  TEXT  10  with  an  edit-format  I 

file,  or  TEXT  10  with  an  unstructured  Tile.  I 
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TEXT  10  supports  four  Tandem  disk  file  types: 

•  Unstructured 

•  Relative 

•  Entry  sequenced 

•  Edit  format 

The  default  file  type  for  TEXT_I0  is  edit  format. 

TEXT_IO  also  supports  terminals  and  spoolers.  The  first  time  a 
program  opens  a  spooler  file,  the  file  uses  level  3  protocols. 
However,  subsequent  spooler  files  do  not  use  level  3  protocols. 

The  range  for  TEXT_I0. COUNT  and  DIRECT_I0.C0UNT  is 
0  ..  L0NG_ INTEGER* LAST.  The  range  for  TEXT_I0. FIELD  is 
0  ..  INTEGER* LAST. 


Pages 


I  For  all  disk  file  types  except  unstructured,  a  form  feed 
I  ( ASCII. FF)  in  a  record  by  itself  marks  the  end  of  a  page. 

I  For  unstructured  files,  a  form  feed  followed  by  a  line  feed 
I  (ASCII. LF)  marks  the  end  of  a  page. 


Lines 


The  maximum  line  length  for  TEXT_I0  is  1320. 

No  character  marks  the  end  of  a  line  in  a  relative,  entry- 
sequenced,  or  edit-format  file. 

For  an  odd  unstructured  file  (ODDUNSTR  parameter  set),  ASCII.LF 
(line  feed)  marks  the  end  of  a  line.  For  an  even  unstructured 
file  (ODDUNSTR  parameter  not  set),  ASCII.LF  marks  the  end  of  a 
line  that  ends  at  an  odd  byte,  and  two  ASCII.LF  characters  mark 
the  end  of  a  line  that  ends  at  an  even  byte. 
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SEQUENT I AL_I 0  supports  only  entry-sequenced  files,  and  DIRECT_IO  I 
supports  only  relative  files.  An  attempt  to  use  SEQUENT  I AL_ 1 0  or  I 
DIR£CT_IO  to  create  any  other  type  of  file  raises  the  exception 
USE_ERROR. 

The  compiler  cannot  instantiate  SEQUENTI AL_IO  or  DIRECT  10  for  an 
unconstrained  type,  except  for  a  record  that  has  discriminants 
with  default  expressions,  in  which  case  the  compiler  chooses  the 
record  length  needed  for  the  largest  possible  object  of  the  type. 
You  cannot  specify  the  record  length  option  for  a  file  that  you 
use  through  the  facilites  of  SEQUENTIAL_IO  or  DIRECT_I0. 

The  following  conditions  also  raise  USE_ERR0R: 

•  An  attempt  to  create  a  new  file  with  the  same  name  as  an 
existing  file 

•  An  attempt  to  create  a  file  for  input 

•  An  attempt  to  create  or  open  a  DIRECT_I0  or  SEQUENTI AL_I0  file 
with  record  size  0 

•  Any  error  in  the  FORM  parameter  of  the  OPEN  or  CREATE 
procedure 

I 

•  In  TEXT_I0,  attempting  to  open  an  existing  entry-sequenced  or  ! 
relative  file  with  a  maximum  record  length  larger  than  1320  I 

I 

•  In  TEXT_IO,  attempting  to  specify  any  file  characteristics  I 

when  creating  an  edit-format  file  I 

An  attempt  to  use  DIRECT_I0  to  read  a  nonexistent  record  raises 
DATA  ERROR. 


File  Closing 


If  a  program  terminates  normally,  the  run-time  routines  automati¬ 
cally  close  STANDARD_OUTPUT .  The  run-time  routines  never  close 
other  files  automatically,  so  we  recommend  that  you  always 
explicitly  close  any  files  that  you  open.  For  example,  if 
you  did  not  close  an  edit-format  file,  it  would  be  left  in  an 
inconsistent  state,  and  the  last  buffer  would  be  missing  from  the 
first  spooler  file  that  you  wrote. 
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Output  Piles 


I  When  a  process  opens  an  existing  SEQUENTI AL_IO  or  TEXT_I0  file 
for  output,  the  run-time  routines  delete  the  file  and  recreate  it 
wit!  the  same  character  ist ics .  The  FORM  parameter  of  the  OPEN 
procedure  provides  the  open-spec  value.  The  default  value  for 
open-spec  is  EXCLUSIVE  for  a  disk  file  or  SHARED  for  any  other 
kind  of  file. 

When  a  process  resets  a  file  for  output,  the  run-time  routines 
delete  and  recreate  the  file  with  the  same  characteristics.  The 
exclusion  mode  is  EXCLUSIVE  for  a  disk  file  and  SHARED  for  any 
other  kind  of  file. 


Operating  System  File  Names 


Each  external  file  name  in  an  Ada  program  must  be  identical  to 
an  operating  system  file  name.  Operating  system  file  names  have 
an  external  and  internal  form,  and  Ada  programs  use  only  the 
external  form.  These  file  names  can  also  be  logical  file  names, 
if  you  use  the  DEFMODE  ON  run  option  when  you  execute  the  Ada 
program. 

If  a  parameter  of  a  TAL  procedure  uses  the  internal  form  of  a 
file  name,  and  an  Ada  program  calls  the  procedure  directly,  the 
Ada  run-time  routines  convert  the  external  name  to  the  internal 
form.  If  the  TAL  procedure  passes  an  internal  name  back  to  an 
Ada  program,  the  Ada  run-time  routines  convert  the  name  to  the 
external  form. 

If  your  Ada  programs  have  TAL  procedures  that  call  other  TAL 
procedures,  you  might  need  to  convert  file  names.  To  convert  the 
external  form  to  the  internal  form,  you  can  use  the  FNAMEEXPAND 
system  procedure.  To  convert  the  internal  form  to  the  external 
form,  you  can  use  the  FNAMECOLLAPSE  system  procedure. 

Disk  file  names  have  the  following  format: 

[\system. ]f lie-name 

File-name  has  the  following  format: 

[$vo2urae. ] [subvolume. ]dlsk-f lie-name 

If  file-name  does  not  include  volume  or  subvolume,  the  compiler 
uses  the  default  volume  or  subvolume  name  provided  by  the 
COMMAND_ I NTERPRETER_ INTERFACE  package.  TEXT  10  does  not  add  the 
system  name  if  the  program  does  not  provide  It. 
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Nar.es 


The  file  names  for  processes  and  devices  have  the  following 
format: 


{ $process } 

[\system.]{  }  [  .  Itnamel  [  .  name2  ]  ] 

{$ device  .} 

A  logical  file  name,  called  a  DEFINE,  has  the  following  format: 

=  name 

To  create  a  DEFINE  and  assign  a  file  name  to  it,  you  can  use  the 
command  interpreter  ADD  DEFINE  command,  in  the  following  format: 

ADD  DEFINE  -name,  FILE  file-name 

To  create  a  DEFINE  from  a  program,  use  the  ADDDEFINE  system 
procedure  instead  of  the  ADD  DEFINE  command. 

For  more  information  on  operating  system  file  names  and  DEFINES, 
see  the  GUARDIAN  Operating  System  User's  Guide  and  the  Labeled- 
Tape  Support  Manual.  For  information  about  the  FNAMEEXPAND, 
FNAMECOLLAPSE ,  and  ADDDEFINE  procedures,  see  the  System  Procedure 
Calls  Reference  Manual. 
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CALLING  SEQUENCES  FOR  EXTERNAL  SUBPROGRAMS 


The  order  in  which  formal  parameters  appear  in  a  subprogram 
declaration  is  the  order  for  pushing  the  corresponding  actual 
parameters  onto  the  data  stack.  Parameter  passing  is  either  by 
value  or  by  reference.  Some  parameters  also  require  passing  a 
descriptor.  The  type  mark  and  the  mode  of  the  formal  parameter 
determines  the  method  for  passing  values. 

Function  subprograms  have  return  values.  Functions  return 
results  either  by  value  or  by  reference.  A  result  that  a 
function  returns  by  reference  can  be  either  of  the  following: 

•  32-bit  extended  address 

•  64-bit  extended  address  pair 


Parameter  Types 


The  following  subsections  describe  parameter-passing  conventions 
for  different  data  types. 


Scalar  Types 


The  calling  program  passes  scalar-type  parameters  of  mode  in  by 
value  in  16,  32,  or  64  bits.  For  objects  less  than  16  bits  in 
length,  such  as  short  enumeration  types  and  BOOLEAN,  CHARACTER, 
and  SHORT_I NTEGER  types,  the  program  passes  the  values  in  16-bit 
containers,  right  justified. 

The  calling  program  passes  scalar-type  parameters  of  mode  out  and 
I  mode  in  out  by  reference  to  a  temporary  variable.  This  is  also 
I  known  as  call  by  value  result.  The  compiler  creates  a  temporary 
variable  for  each  actual  parameter.  The  calling  program  passes 
I  the  temporary  variable  addresses  to  the  called  subprogram.  For 
I  objects  that  are  8  bits  in  length,  the  program  passes  32-bit 
extended  addresses.  For  all  other  objects,  the  program  passes 
16-bit  word  addresses. 
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Array  and  Record  Types 


For  array  and  record  types,  the  calling  program  passes  parameters 
of  all  modes  by  reference.  If  an  actual  parameter  specifies  a 
type  conversion,  the  program  passes  the  address  of  a  temporary 
variable.  Otherwise,  the  program  passes  the  address  of  the 
actual  parameter  itself. 

If  the  formal  type  mark  of  the  actual  parameter  is  constrained 
or  unconstrained,  the  calling  program  passes  a  32-bit  extended 
address  for  the  actual  parameter.  If  the  type  mark  is 
unconstrained,  the  program  also  passes  an  additional  32-bit 
extended  address  of  the  descriptor  of  the  actual  parameter.  The 
descriptor  pointer  comes  immediately  after  the  pointer  to  the 
object  itself. 


Access  Types 


For  access  types,  the  calling  program  passes  parameters  of  mode 
in  by  value  in  either  32  or  64  bits.  If  the  formal  type  mark 
is  constrained,  the  program  passes  a  32-bit  extended  address  of 
the  object.  If  the  type  mark  is  unconstrained,  the  program 
passes  a  64-bit  value,  consisting  of  a  32-bit  extended  address  of 
the  object  followed  by  a  32-bit  extended  address  of  the  object 
descriptor.  If  the  access  type  denotes  an  accessed  type  that  is  I 
not  completed  in  the  same  compilation  with  its  incomplete  type  I 
declaration,  the  size  is  64  bits.  I 

The  calling  program  passes  access-type  parameters  of  mode  out  and 
mode  in  out  by  reference  to  a  temporary  variable,  using  16-bit  I 
word  addresses,  just  like  for  scalar  types.  The  compiler  creates  I 
a  temporary  variable  for  each  actual  parameter.  The  calling  ! 

program  passes  the  temporary  variable  addresses  to  the  called  I 

subprogram.  Each  address  points  to  a  32-bit  or  64-bit  object,  I 
depending  on  whether  the  accessed  type  is  constrained  or  uncon-  I 
strained  and  on  whether  the  accessed  type  is  completed  in  the  I 

same  compilation,  as  described  in  the  preceding  paragraph.  I 


Static  Link  for  Nested  Subprograms 


A  nested  subprogram  is  a  subprogram  to  which  the  stack  frame  of 
some  lexically  enclosing  subprogram,  block,  or  task  is  visible. 
Every  nested  subprogram  has  a  static  link  that  the  subprogram 
-s«s  to  refer  to  objects  allocated  in  enclosing  stack  frames. 
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The  static  link  is  a  16-bit  quantity  that  contains  the  address  of 
the  stack  mark's  L-register  component  of  the  immediate  lexically 
enclosing  stack  frame.  The  calling  program  passes  the  static 
link  value  to  a  nested  subprogram  by  value  as  the  last  actual 
parameter.  This  affects  TAL  procedures  that  have  nested  Ada 
specifications.  Such  procedures  should  expect  an  extra  16-bit 
value  pasted  on  the  stack. 


Function Returns 


The  following  subsections  describe  how  functions  return  results 
of  different  data  types. 


Scalar  Types 


For  scalar  types,  functions  return  results  by  value  on  the 
register  stack.  Results  are  16,  32,  or  64  bits  long.  Functions 
return  scalar  results  shorter  than  16  bits  in  16-bit  containers, 
right  justified,  with  sign  extension  for  signed  values  and  zero 
extension  for  unsigned  values. 


Composite  Types 


For  array  types  and  record  types,  functions  return  results  by 
reference  as  if  the  functions  were  access  types.  If  the  type 
mark  of  the  function  return  value  is  constrained,  then  the 
function  returns  the  32-bit  extended  address  of  the  result.  If 
the  type  mark  is  unconstrained,  then  a  64-bit  value  is  returned, 
including  a  32-bit  extended  address  of  the  array  or  record 
followed  by  a  32-bit  extended  address  of  the  descriptor  of  the 
result . 


Access  Types 


For  access  types,  functions  return  results  by  value  in  either  32 
or  64  bits,  as  for  scalar  types. 
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GENERIC  INSTANTIATIONS 


The  compiler  expands  generic  units  at  the  point  of  instantiation. 
A  generic  body  must  be  in  the  same  compilation  as  its  specifica¬ 
tion  and  must  occur  after  the  specification.  Any  subunits  of  a 
generic  unit  must  also  be  part  of  the  same  compilation  that  the 
parent  is  in  and  must  follow  the  parent  in  the  compilatfon. 


MEMORY  USAGE  ON  NONSTOP  SYSTEMS 


A  program  running  under  the  GUARDIAN  90  operating  system  stores 
data  either  in  its  128K-byte  data  segment  or  in  extended  memory. 
A  program’s  extended  memory  can  consist  of  several  extended 
segments,  each  as  large  as  128  megabytes.  An  Ada  program  uses 
only  one  extended  segment,  whose  initial  size  can  grow  to  128 
megabytes,  as  needed. 


Main  Task  and  Active  Task 


An  Ada  program  contains  a  main  task  and  possibly  other  tasks.  At 
any  time  only  one  task  is  active.  Whether  active  or  not,  a  task 
has  a  stack  of  frames  in  which  it  stores  objects. 

For  the  main  task,  the  stack  contains  objects  declared  within  the 
main  program,  objects  declared  within  subprograms  called  from  the 
main  program,  and  so  on.  When  the  program  creates  a  new  task, 
the  frames  visible  then  are  logically  part  of  the  new  task's 
stack,  which  diverges  after  that. 


Memory  Stack  and  Data  Segment 


The  first  haif  (64K  bytes)  of  the  data  segment  is  called  the 
memory  stack.  It  contains  the  stack  frames  visible  to  the  active 
task.  Composite  objects  are  not  stored  in  these  frames. 

When  a  different  task  becomes  active,  frames  no  longer  visible 
to  the  new  task  are  swapped  out  of  the  memory  stack.  Frames 
that  are  visible  to  the  new  task  but  were  not  visible  to  the 
previously  active  task  are  swapped  in. 

The  second  half  (64K  bytes)  of  the  data  segment  contains  global 
package  data  for  the  various  packages  in  the  program,  except  for 
composite  objects. 
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Extended  Stacks 


Each  task,  including  the  main  task,  also  has  an  extended  stack. 
Frames  in  the  extended  stack  correspond  either  to  frames  in  the 
memory  stack  or  to  frames  swapped  out  of  it.  Extended  stack 
frames  store  composite  objects. 

You  can  specify  the  size  of  the  extended  stack  for  the  main  task 
in  the  EXTENDED_STACK_S I ZE  switch  of  the  ADABIND  command.  The 
default  size  is  2  **  18  bytes,  and  you  can  specify  a  size  greater 
than  0  and  less  than  2  **  27  bytes. 

The  size  of  extended  stacks  for  tasks  other  than  the  main  task 
is  256K  bytes,  by  default.  You  can  specify  a  different  value  in 
a  STORAGE_S I ZE  representation  clause  for  the  corresponding  task 
type. 


Extended  Data  Segment 


The  extended  data  segment  contains  the  extended  stacks,  composite 
global  package  data,  frames  swapped  out  of  the  memory  stack, 
objects  created  by  allocators,  and  other  program  data.  The 
compiler  reclaims  the  space  from  any  temporary  variables  it 
I  creates  for  execution  of  a  subprogram.  There  is  no  way  to  reuse 
I  the  space  from  objects  created  by  allocators. 

If  the  extended  data  segment  needs  to  be  larger  than  128 
megabytes  for  the  program  to  run,  the  program  raises  the 
exception  STORAGE_ERROR.  It  also  raises  STORAGE_ERROR  if  any 
task  needs  more  space  than  that  allocated  for  iti  extended 
stack,  if  the  memory  stack  needs  more  than  64K  bytes,  or  if  the 
noncomposite  global  package  data  needs  more  than  64K  bytes. 
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COMPLETION  CODES  FOR  COMPILER  AND  ADABIND  PROCESSES 


Each  compiler  or  ADABIND  process  supplies  a  completion  code  value 
upon  exit  to  the  operating  system.  Table  F-5  shows  the  possible 
completion  code  values  and  their  meanings. 


Table  F-5.  Completion  Codes 


Value 

Meaning 

0 

The  process  terminated  normally  with  no  errors. 

1 

Warning  messages  were  issued. 

2 

The  compiler  or  ADABIND  process  detected  one  or 
more  fatal  errors,  including  source  code  errors 
or  the  inability  to  open  specified  files. 

5 

The  process  terminated  abnormally  due  to  an 
error  in  the  compiler  or  ADABIND. 

IMPLEMENTATION  LIMITS 


Table  F-6  lists  some  Tandem  Ada  limits  on  the  use  of  language 
features. 
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Table  F-6.  Implemeatat ion  Limits 


Language  Feature 


Maximum  Number 


Characters  in  an  identifier 
Characters  in  a  line 
Discriminants  in  a  constraint 
Associations  in  a  record  aggregate 
Fields  in  a  record  aggregate 
Formal  parameters  in  a  generic  unit 
Nested  contexts 
Bytes  for  an  object 

Words  of  object  code  for  a  subprogram 
Library  units  in  a  program 

Compilation  units  and  subprograms  in  a  program 
(The  compiler  reserves  approximately 
1,000  entries  for  run-time  routines.) 

Units  named  in  a  compilation  unit's  with  clauses 

Dynamic  components  in  a  record 

Array  dimensions 

Control  statement  nesting  level 

Literals  for  an  enumeration  type 

Tasks  for  a  program 

Entries  for  a  task 

Subprogram  nesting  level  in  a  calling  sequence 
(For  example,  f(f(f(x)))  has  3  nesting 
levels . ) 

Unique  strings  and  identifiers  for  a 
compilation  unit 


200 

200 

256 

256 

256 

256 

250 

32766 

32767 
500 

-15000 

255 

256 
7 

256 

32767 

32767 

32767 

25b 


4096 
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Certain  tests  in  the  ACVC  make  use  of  implementation-dependent  values ,  such 
as  the  maximum  length  of  an  input  line  and  invalid  file  names.  A  test  that 
makes  use  of  such  values  is  identified  by  the  extension  .TST  in  its  file 
name.  Actual  values  to  be  substituted  are  represented  by  names  that  begin 
with  a  dollar  sign.  A  value  must  be  substituted  for  each  of  these  names 
before  the  test  is  run.  The  values  used  for  this  validation  are  given 
below. 


Name  and  Meaning _  Value _ 

$BIG_ID1  (1..199  =>  'A',  200  =>  ' 1 ' ) 

Identifier  the  size  of  the 
maximum  input  line  length  with 
varying  last  character. 


$BIG_ID2  (1..199  =>  'A',  200  =>  ’2’) 

Identifier  the  size  of  the 
maximum  input  line  length  with 
varying  last  character. 


$BIG_ID3  (1..99  =  >  ’A',  100  =>  '3',  101. .200  =>  'A') 

Identifier  the  size  of  the 
maximum  input  line  length  witn 
varying  middle  character. 


$BIG_IDM 

Identifier  the  size  of  the 
maximum  input  line  length  with 
varying  middle  character. 

*BIG_INT_LIT 

An  integer  literal  of  value  293 
with  enough  leading  zeroes  so 
that  it  is  the  size  of  the 
maximum  line  length. 


(1..99  =>  ’A’,  100  =>  *  U • ,  101. .200  z>  'A') 


•  1..197  s  >  'O',  196. .  200  *>  "293") 


C-l 


'EST  PARAMETERS 


Name  and  Meaning _ _ _ _ 

$EIG_REAL_LIT 

A  real  literal  that  can  be 
either  of  floating-  or  fixed- 
point  type,  has  value  690.0,  and 
has  enough  leading  zeroes  to  be 
the  size  of  the  maximum  line 
length. 

$BLANKS 

A  sequence  of  blanks  twenty 
characters  fewer  than  the  size 
of  the  maximum  line  length. 

$COUNT__LAST 

A  universal  integer  literal 

whose  value  is  TEXT_I0. COUNT' LAST. 

$EXTENDED_ASCII__CHARS 

A  string  literal  containing  all 
the  ASCII  characters  with 

printable  graphics  that  are  not 
in  the  basic  55  Ada  character 

set. 

$FIELD_LAST 

A  universal  integer  literal 

whose  value  is  TEXT_I0. FIELD 'LAST. 

$F  I  LE_N  AMEJrf  I  TH_BAD_C  HARS 

An  illegal  external  file  name 
that  either  contains  invalid 
characters,  or  is  too  long  if  no 
invalid  characters  exist. 

$FILE_NAME_WITH_WILD_CARD_CHAR 

An  external  file  name  that 

either  contains  a  wild  card 
character,  or  is  too  long  if  no 
wild  card  character  exists. 

$G RE AT ER_THAN_D U RA TI ON 

A  universal  real  value  that  lies 
between  DURATION '  BASE'  LAST  and 
DURATION' LAST  if  any,  otherwise 
any  value  in  the  range  of 
DURATION. 

>GREATER_THAN_DURATION_BASE_L AST 

The  universal  real  value  that  is 
greater  than  DURATION 'BASE' LAST, 
if  such  a  value  exists. 


Value _ 

(1..194  =>  'O',  195. .200  =>  "C9.0E1") 

(1 . .180  =>  '  ’) 

2_147_483_647 

"abcdefghi  jklmnopqrstuvwxyzl  $$?@[  \ ]*'  {} " 

32767 

X }  ] !  @ 

XYZ# 

100_000.0 

100  000  000.0 


EST  PARAMETERS 


Name  and  Meaning _ Value _ 

$ILLEGAL_EXTERNAL_riLE_NAME1  bad-character*‘ 

An  illegal  external  file  name. 

$ILL3GAL_EXTERNAL_FILE_NAME2  muchtoolongname 

An  illegal  external  file  name 
that  is  different  from 
$ I L L B3  AL_EX TEK  NA  L_F I LE_K  AME 1 . 

$INTEGER_FIRST  -32768 

The  universal  integer  literal 
expression  whose  value  is 
INTEGER 'FIRST. 


$INTSGER_LAST  32767 

The  universal  integer  literal 
expression  whose  value  is 
INTEGER' LAST. 


$LESS_THAN_DURATION  -100_000.0 

A  universal  real  value  that  lies 
between  DURATION 'BASE' FIRST  and 
DURATION 'FIRST  if  any,  otherwise 
any  value  in  the  range  of 
DURATION. 

$LESS_THAN_DURATION_BASE_FIRST  -100_000_000.0 

The  universal  real  value  that  is 
less  than  DURATION 'BASE' FIRST, 
if  such  a  value  exists. 

$MAX_DIGITS 

The  universal  integer 
whose  value  is  the 
digits  supported 

floating-point  types. 

$KAX_IN_LEN  200 

The  universal  integer  literal 
whose  value  is  the  maximum 
input  line  length  permitted  by 
the  implementation. 


literal 

maximum 

for 


$MAX_INT  9_2  2  3_3 7 2_0  3  6_8  5  ^_7 7  5_8  0  7 

The  universal  integer  literal 
whose  value  is  SYSTEM. MAX  INT. 
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Value 


$NAME  L0NG_L0NG_INT3GER 

A  name  of  a  predefined  numeric 
type  other  than  FLOAT,  INTEGER, 

SHORT_FLOAT,  SHORT_INTEGER , 

LONG_FLOAT,  or  LONG_INTEGER 
if  one  exists,  otherwise  any 
undefined  name. 


$NEG_BASED_INT  1 6  #FFFF_FFFF_FFFF_FFFE# 

A  based  integer  literal  whose 
highest  order  nonzero  bit 
falls  in  the  sign  bit 
position  of  the  representation 
for  SYSTEM. MAX  INT. 


$NON_A  SC I I_CHAR_TY PE  (NON_NULL) 

An  enumerated  type  definition 
for  a  character  type  whose 
literals  are  the  identifier 
NON_NULL  and  all  non-ASCII 
characters  with  printable 
graphics. 
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Some  tests  are  withdrawn  from  the  ACVC  because  they  do  not  conform  to  the 
Ada  Standard.  The  following  19  tests  had  been  withdrawn  at  the  time  of 
validation  testing  for  the  reasons  indicated.  A  reference  of  the  form 
"Al-ddddd"  is  to  an  Ada  Commentary. 


.  C32114A:  An  unterminated  string  literal  occurs  at  line  62. 

.  B33203C:  The  reserved  word  "IS"  is  misspelled  at  line  45. 

.  C34018A:  The  call  of  function  G  at  line  114  is  ambiguous  in  the 
presence  of  implicit  conversions. 

•  C35904A:  The  elaboration  of  subtype  declarations  SFX3  and  SFX4 

may  raise  NUMERIC_ERROR  instead  of  CONSTRAIN T_ERROR  as  expected  in 
the  test. 

.  B37401A:  The  object  declarations  at  lines  126  through  135  follow 

subprogram  bodies  declared  in  the  same  declarative  part. 

.  C41404A:  The  values  of  'LAST  and  'LENGTH  are  incorrect  in  the  if_ 

statements  from  line  74  to  the  end  of  the  test. 

.  B45116A:  ARRPRIBL1  and  ARRPRIBL2  are  initialized  with  a  value  of 

the  wrong  type— PRIBOOL  TYPE  instead  of  ARRPRIBOOL  TYPE— at  line 
41. 

.  C48Q08A:  The  assumption  that  evaluation  of  default  initial  values 

occurs  when  an  exception  is  raised  by  an  allocator  is  incorrect 
according  to  AI-00397* 

.  B49006A:  Object  declarations  at  lines  41  and  50  are  terminated 

incorrectly  with  colons,  and  end  case ;  is  missing  from  line  42. 

.  B4A010C:  The  object  declaration  in  line  18  follows  a  subprogram 

body  of  the  same  declarative  part. 
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.  B74101B:  The  begin  at  line  9  causes  a  declarative  part  to  be 

treated  as  a  sequence  of  statements. 

.  C87B50A:  The  call  of  "/="  at  line  31  requires  a  use  clause  for 

package  A. 

.  C92005A:  The  "/="  for  type  PACK.BIG_INT  at  line  40  is  not  visible 

without  a  use  clause  for  the  package  PACK. 

.  C940ACA:  The  assumption  that  allocated  task  TT1  will  run  prior  to 
the  main  program,  and  thus  assign  SPYNUMB  the  value  checked  for  by 
the  main  program,  is  erroneous. 

.  CA3005A. .D  (4  tests):  No  valid  elaboration  order  exists  for  these 

tests. 

.  BC3204C:  The  body  of  BC3204C0  is  missing. 
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